What about this?

[David E. Manifold]

On Sun, 8 Feb 1998, Maneesh Yadav wrote:

> 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).
> 
> I see a lot of "big" prgrams out there are mostly data.... storing only the
> code part in a portable form and a compiled I think is not such a bad idea
> (how do you share data betwwen the HLL and compiled form, well I have further
> ideas about how programs should store data, but for now just humour me)...
> you get portability and performance...
> 
> I say this is reasonable since memory is cheap and is getting cheaper, after
> all we do things in games today that we wouldn't have dared do a few years
> ago simply because we had a limited amount of CPU speed...
> 
> Perhaps there could be protection access specifiers to mark something as un
> exportable, in order to prevent sending very hardware specific things (memory
> managers, pagers etc.) and saving space....
> 
> 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...
> 
> So whatdya think?
> 
You are still thinking like we are system designers.
We are not.
We are making a system to allow others to develop their system.
This means, we don't put in "protection access specifiers" or come up with
a "standard HLL format".  The TUNES system allows high level, detailed
specification PER OBJECT of what representation it is stored in, how it is
transmitted across the network, and whether platform-dependent
representation will be stored along with the object.  We will not add the
things you speak of.  We will allow people to talk about all these things,
and choose to do it in the way they think best.  
In my opinion, I believe that these issues (low-level representation and
distribution formats) will become ones that people no longer deal with.
Formats do not affect high-level meaning, and the everyday user does not
want to deal with them.  The information stored and transmitted will vary
from system to system, and from minute to minute.  Formats will be
dynamic and automatic.  You simply say, "for these objects, keep the
compiled code cached because I intend to use it often."  Or, more likely,
you will simply note that you intend to use these objects often, and the
system will more efficiently determine whether or not to keep the compiled
code, or delete it and reevaluate the source later.  And, ultimately, you
won't even have to say you will use the objects often, because the system
will be able to notice you are using them often, and guess at the future
based on the past.  You will be able to customize the optimizer behavior
to any extent you wish.  This is a long way off, however, because someone
has to design optimization rules, AFTER we make the initial abstract
reflection tree.

David E. Manifold <dem@pacificrim.net> http://www.pacificrim.net/~dem/