What about this?

[Fare Rideau]

>: Maneesh

> Thinking about the byte code thing....
> I'm begining to think that storing programs in a standard HLL format and a
> compiled format on each machine is a reasonable method for portability,
> instead of having some sort of assembly to HLL inverter (geeze that'd be
> pretty hard to write).
The question of FAT binaries has been rebated to death on the list before.
My personal conclusion was that SLIM binaries (as in Juice) were much better,
with FAT parts just where it's needed, that is, performance-intensive
parts (hey! I'm talking about code, not women).
Actually, much like SLIM binaries are better than bytecode because
they are higher-level, meta-SLIM binaries could have "better FAT",
with arbitrary implementation notes/tactics instead of mere
"do it exactly like on this CPU family" stuff
(which doesn't even adapt well to processor personality in the family).

> Perhaps we wouldn't even need to store the HLL format, except as a link to
> another machine which stores it where you download the program and your
> machine compiles it...
This is all a matter of caching over the network, independently from
any underlying implementation, as long as it's structured enough.
The usual questions about network caching are:
what are you ready to trust, and how do you schedule it for good performance?
They can be fully dissociated from the program encoding problem.

Best regards,

## Faré | VN: Уng-Vû Bân   |    TUNES is a Useful, Not Expedient System     ##
## FR: François-René Rideau | Project for a Free Reflective Computing System ##
## Reflection&Cybernethics  |          http://www.tunes.org/~tunes           ##
First Rule of History:
        History doesn't repeat itself -- historians merely repeat each other.