on the HAL-9000

[RE01 Rice Brian T. EM2]

>In my opinion, Tunes should be as close to the 'total reflection at
>all costs' side of the curve as possible. For situations where
>performance is more important, there should be a path for letting
>people who know about optimization on the hardware plug in optimizers
>which will help make the code that actually runs more static. It
>should be Tunes' job to keep even this static code tied to the high
>level description of the same code, so that it can always reflect on it.

I agree about linking the executable code with its high-level
representation.  However, does just the 'definition' of the program (the
semantics that the user manually applied to create the code) apply when
speaking of a program's relation to the system?  Theoretically, every
piece of semantics-code applies to every running algorithm.  For
example, the memory-management aspect of generating code obviously
applies to everything in the run-time.  After all, shouldn't the code
generator generate space-efficient code even if the user doesn't
explicitly state so?  Alternatively, such aspects could be already
included implicitly in the language modules suggested to the user.  The
latter seems more appropriate.
I've already stated my position on monolithic compilers.  To me, it
seems against the direction of the project.

>As a small concrete example, if your language lets you make a
>data-structure, how tunes represents this on the hardware should be
>irrelvant. When you write code to deal with this data structure, Tunes
>(and the underlying compiler) should be able to generate static code
>which access this data structure as if it were a static structure, if
>you use some kind of reflection to get at the data, Tunes will know
>the static layout of the structure in memory. If you use reflection to
>add a data-member to the structure, Tunes can decide whether or not to
>invalidate the static code and recompile it.

hmm... I'll come up with a corresponding example to illustrate my point
of view on that.
>