[E-Lang] New Page: Partially Ordered Message Delivery

[Marc Stiegler]

----- Original Message -----
From: Tyler Close <tclose@oilspace.com>
To: Mark S. Miller <markm@caplet.com>
Cc: E Language Discussions <e-lang@eros-os.org>
Sent: Wednesday, March 07, 2001 6:59 AM
Subject: RE: [E-Lang] New Page: Partially Ordered Message Delivery


> MarkM wrote:
> > Due to limited time, and to the difficulty people have had
> > learning Hydro
> > well enough to give me feedback,
>
> The only person I ever heard from was MarcS. He was having trouble
> constructing new containers. Consequently, I introduced the
> Initializer class to simplify this. He seemed pretty happy after that.

Tyler, I sympathize with your heartburn that progress towards a native
immutable collection system has been lacking in E, though I also understand
why this has been more heartburn for you than for me...and it is also clear
that somewhere we had a miscommunication, because I have never endorsed
figuring out how to integrate Hydro syntactic shorthand before v1.0 of E
shipped, it has always wound up in my list of "blasted, can't squeeze it
into version 1 no matter how cool it would be".

Here are my observations, which include the two requirements that have to be
met before I could endorse your proposal. Let me confirm that I have the
proposal correct: discard the current List and Map from E and incorporate
syntactic shorthands for Hydro structures instead.

Observations:

--I am an enthusiast for changing E to use immutable collections-only, no
mutable ones. It would have great security properties. And not having a
built-in queue in E is quite inconvenient. And in our earlier emails, you
convinced me that immutable collections could be made to look comfortable
enough for Java programmers that I could endorse the concept.

--However, my very enthusiasm is a disadvantage for this analysis. So my
first requirement (sorry to toss out another requirement not mentioned
before...though we are discussing something different from what I'd endorsed
before, namely, immediate elimination of List/Map :-) is that Ppooko also
endorse the proposed Hydro shorthands. One strategy for achieving Ppooko
endorsement would be to create a blend of shorthands that encompass both E
Lists/Maps and Hydro, though it would of course be better if Ppooko could
endorse a Hydro-only shorthand. Certainly, our earlier go-round on this
suggested that clean shorthands for both Hydro and List/Maps together would
be at best difficult to achieve (though on this list we have achieved so
many "simply better" solutions lately, I cannot call it impossible).

--Trust is a peculiar and many-splendored thing. Putting stuff this deeply
into the E infrastructure requires special forms of trust. Since I am going
to talk about trust in this paragraph, and people tend to be sensitive about
trust, people should read it very very carefully before they get huffy about
the things I say here.

On the one hand, I trust markm as a software engineer/architect more than I
trust myself. On the other hand, I wish I could have a second person whom I
trust at least as much as I trust myself review all markm's E code. As it
stands, my code and all E code is "at the mercy of" markm. It is also,
incidentally, "at the mercy of" bill's code (whom I trust to write secure
software more than I trust myself). This is 2 too many people to be at the
mercy of already, but that is the way it is, and I can think of very few
people I would be equally willing to be at the mercy of.

Tyler, I have less personal experience with your stuff. Despite that, for
various reasons having to do with the interactions we have had so far, I
actually trust you more than I trust myself for building high-performance
software. (In the spirit of utter candor, I have to say, your naming choices
leave me astonished sometimes, as we discussed in our earlier Hydro
discussion, where you staunchly defended the Hydro usage of terminology
calling a "stack" a "lifo queue". But in fact, this terminology disagreement
is irrelevant with the right syntactic shorthand in E, these terms would
never see the light of day). However, the data structures in E are so
fundamental, there is more to their correct construction than their
performance characteristics. And though I think I actually trust you more to
build fundamental data structures than I trust myself, I trust myself very
little on this matter because dean and markm have made me, over the course
of a decade, very aware of just how subtle fundamental data structure errors
can be. And anyway, putting the language "at the mercy of" more people is
the wrong direction to be going. Therefore my second requirement: I
desperately want Hydro to be reviewed by someone whom I trust a bunch more
on these kind of data structures than I trust myself. So before I could
endorse discarding List/Map for Hydro, I would like (well, really, need) to
see someone like markm  (profoundly not available) or dean (dean, any
chance?), or another person whom markm or dean could endorse,  review and
endorse Hydro.

-- The third problem is the actual manpower to make the change. I believe,
Tyler, you had already volunteered to create the changes to E needed for
this change. Assuming this is true, this one is not a problem once the other
2 hurdles have been cleared.

Having said that, this is a great moment in the history of E to figure out
the right answer, since we changed everything else so much anyway :-)

Dean, markm, any proposals for people who might be appropriate to review
Hydro? I could expect this to be an uncomfortable conversation, so I would
propose pursuing this privately for the moment. Note that this assignment is
slightly lighter weight than it might be in a closed-source world: one
merely has review Hydro far enough to conclude that any flaws could be fixed
without changing the syntactic shorthand in E, and that would be enough for
the moment. Which brings us to the second topic, which is the syntactic
shorthand:

Tyler, could you reprint your original proposal for Hydro syntax for Ppooko
to review? I observe that the proposal needs to be slightly modified now
anyway, at least to the extent of using "var" rather than "def" for objects
that replace themselves with altered versions of themselves. Tyler, you
might also want to (probably privately) propose possible reviewers to markm
and dean, see if there is any overlap in people who perhaps have already
reviewed Hydro and people they can endorse.

--marcs