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
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.
Cheers,
--MarkM