Build Problems Resolved

[Mark S. Miller]

At 08:34 AM 9/5/99 , Paul Snively wrote:
>Thank you for clarifying that I'd failed to make myself clear. ;-) I am 
>absolutely NOT advocating tight implementation coupling--far from it. If 
>I'm saying anything, I'm saying that E as it stands right now strikes me 
>as *having* too-tight coupling, in particular to being Java-based, and 
>that *perhaps* a closer look at the parsing/interpreting components 
>*might* lead us to an alternative approach--ANTLR/tree parsing-based or 
>otherwise--that lends itself to *abstracting out* the entire codegen 
>process so that we could *both* go Java bytecodes, thereby getting us 
>everywhere we currently are but hopefully in a more modular fashion, *and* 
>go native to various processor/OS combos, e.g. EROS on Pentiums.

My point is that it is not the parsing/codegen/virtual machine that ties us 
to Java.  It is their large set of libraries that we wish to inherit 
without reimplementing.  Languages, however beautiful, without such rich 
libraries do not catch on anymore.  However, as I mentioned before, the 
(yet to be rigorously defined) subset of E for writing confined smart 
contracts could be retargetted to other platforms, and I welcome anyone to 
do so.  The difference between E and this subset?  Only what libraries are 
available.  The language per se is identical, so all of the kind of work 
you mention above would apply directly.

I would be ecstatic if someone were to volunteer (hint hint) to rewrite the 
parser in ANTLR, or to write a code generator using ANTLR.  If they were to 
write the code generator in a modular retargettable fashion, so much the 
better!

In any case, none of this effects the overall coupling point I was 
making.  The parser, interpreter, and not-yet-existent code generator are 
small parts of the E system.  They could be replaced wholesale without 
effecting anything else.  And it would be great if someone did so!

>My point here was just that once you introduce native anything through 
>JNI, you might just as well put forth the moderate extra effort to get 
>where else you wish to be. I should confess that when I think of ColdStore 
>and EROS, the commonality I see consists of orthogonal persistence, and I 
>gloss over the myriad implementation differences that would clearly be 
>necessary to target the two systems.

>Truthfully, I don't know. I *suspect* by making EROS address the issue of 
>orthogonal persistence rather than E.

I am in love with EROS's orthogonal persistence, but

1) Although E should be made to run well on EROS, it cannot depend on 
EROS.  E must also run adequately well on the 3 standard platforms.  In 
order: Windows98/NT, Linux/Solaris, and Mac.  E must have a persistence 
solution that works on all three.

2) There are two necessary problems that non-orthogonal persistence 
mechanisms (manually written "save" code) normally solve.  Fully orthogonal 
persistence -- as in EROS and the persistence system I build at 
Communities.com for Original-E -- only solve one.  The two problems are 
having computation state (or a useful subset thereof) survive machine 
failures (persistence per se), and having this state survive into a new 
release of the program that it instantiates (the upgrade problem).

After I almost killed us at Communities.com with a fully orthogonal 
approach, in which upgrade was intractable, Arturo had the great insight 
that I call the semantic funnel: the programmer must specify the small 
subset of computation state that they are committing to support through 
future upgrades.  This must be a deliberate and manual choice, however much 
automatic support we provide to make it pleasant.  The programmer must 
then, of course, figure out how to revive the rest of their computation 
from this saved state.  Each mutually suspicious component of a system must 
be able to restore in this manner without vulnerability to the other 
components doing likewise.  The relationships among such components must be 
restored as part of this process.

We have to have this logic for supporting upgrade, even if we were 
operating only on EROS.  However, when on EROS we would plausibly use this 
logic *only* for upgrade, whereas on other platforms we'd use it for both 
persistence and upgrade.  EROS therefore won't save us any code, but it 
will allow our persistence to be higher fidelity and higher performance.

>I haven't thought any of this through completely, nor have I groveled over 
>the code, so I'm quite literally just thinking out loud at this point--my 
>apologies if it's wasting too much of your time.

Ah, another apology.  You are forgiven again!

>A true prospect as depressing as the true prospect that the x86 
>architecture is the x86 architecture of the personal computing world.

Yes, I intended the depressing aspects of the analogy.  However, notice how 
little most of us care anymore about the instruction set.  People who write 
code generators or operating systems are still put through hell, but their 
efforts save the rest of us from that hell.  We are already approaching the 
same fortunate situation regarding jvms.  Pick your battles.  I no more 
want to fight the jvm tidal wave than I want to fight the x86 one.



         Cheers,
         --MarkM