Priorities

[Laurent Martelli]

>>>>> "David" == David Jeske <jeske@home.chat.net> writes:

    >> >* Try to figure out what to change in the source code to
    >> correspond with >the binary change you made. (you and the
    >> system would work together on >this, i.e. the system would try
    >> to figure it out but you would help if it >failed) It may not
    >> be possible to express the change in the language used >in the
    >> source, if so, then one of the below options would have to be
    >> used.
    >> 
    >> This is just too *unrealistic* to be commented.

    David> If you consider this just 'some level of translation' and
    David> 'some other level of translation', it may make a bit more
    David> sense. Imagine using a 'lisp -> C' compiler (which exists
    David> TODAY). In Tunes, we would hope that even after the
    David> translation, you could go in and change the C code, and see
    David> the change reflected in the lisp code. The translations are
    David> not just 'one shot' operations, but instead they are links
    David> between two different representations of the same piece of
    David> functionality.

Translating Lisp to C looks alright to me, but modifying the generated
C scares me. And I don't think that it is possible to to compute
change in the lisp source for any change you can make in the C
corresponding source. Because they do not handle the same concepts. C
is lower level than Lisp. You can write equivalent programs in C and
Lisp, but I doubt that you can compute a Lisp source  equivalent to a
C source in a reasonable amount of time. And I don't see why I would
want to do it.


    David> Consider 'changing binary code' just 'providing an assembly
    David> optimized version of a function'. People do that all the
    David> time. When you do something like provide a target optimized
    David> version of a function, there should still be the platform
    David> independent implementation. The system should be
    David> responsible for composing the appropriate blocks into a
    David> running program. If possible, it would be nice to have the
    David> system be capable of understanding the hand-optimized
    David> version. Perhaps someday it may even be able to compare the
    David> hand-optimizer version with the high-level language version
    David> to test their equivilance. The important part is that
    David> enough meta-information about the blocks be stored _in the
    David> running system_, for software to be later written to
    David> perform these tasks.

I'd rather have an open compiler to which I can add optimization rules
than build hand crafted otpimisations for every functions. 


    David> It's something like the new Java HotSpot VM which is not
    David> yet released. HotSpot is based on the self dynamic
    David> recompilation technology. (self.sunlabs.com) The Java VM
    David> (IMO) is broken in many ways, mostly because they polluted
    David> the runtime with a 'class-based object model'. However,
    David> there are defeinetly blocks of code which are faster in
    David> HotSpot/Self, and there are blocks of code which are faster
    David> in traditional static languages. Some projects are trying
    David> to bring the benefits of dynamic recompilation to static
    David> languages (go look for `C, Tick-C, off the MIT Exokernel
    David> pages). Tunes intends to follow Self a bit more in doing
    David> dynamic recompilation.

Yes. I am a great Emacs fan because changes are taken into account
automatically, without having to recompile. But I realzie that the
portion of the code that I modify is very small. So I could compile
all the code that I do not touch, and have the benefits if both world
(compilation and interpretation). And the system could manage
dependencies and know when a compiled and optimized version of a
function is outdated. 

Laurent