[E-Lang] A more critical question (was: an example impatience policy )

[Mark S. Miller]

At 11:15 AM Wednesday 3/21/01, Tyler Close wrote:
>One of the main worries that MarkM expressed with Hydro is that it is
>not tightly bound to the rest of the E code base. That he doesn't get
>that this is a good thing is, in my view, the source of E's shipping
>problems.

Rather than "tightly bound", what I said was "evolved separately" and "not 
well integrated".  Although Hydro is separable from Droplets, the two 
evolved together and are well integrated.  I'm not seeking thicker 
interfaces and tighter coupling.  I am seeking consistency and coherence 
between the parts of E, just as you do for the parts of your overall system.

Btw, ELib is separable, and can be shipped and used separately from the E 
language.  However, as with Hydro & Droplets, they evolved together to play 
well together.

Earlier I said:

>                             Can we postpone deciding?
>
>While we examine the overall integration question, we should also ask the 
>earlier question:
>
>Can we define what E is, such that the collections may be provided by Hydro 
>or not, but the language is still the same?  Language design and library 
>design should normally be kept separate, but primitive data types are
>where they intersect.  How much of E do we need to agree on in order for 
>Tyler and E to separately proceed forward before deciding on the Hydro-E 
>question, but where we're proceeding with compatible notions of E? [...]


So it seems we share the same desire.  But we still need to figure out what 
to do.  Starting from Kernel-E, and thereby ignoring the syntax expansion 
issues, it seems the collection classes that are a necessary part of the 
definition of Kernel-E are a string type and an immutable list type, since a 
match clause in an object definition reifies an incoming message into the 
message name and the list of arguments:

    def forwarder {
        match [verb, args] {
            # ...
        }
    }

Within the match clause, Kernel-E must say what kind of things the variables 
"verb" and "args" are bound to, and what messages may be sent to these kinds 
of things.  That's why we can't agree even on what Kernel-E is if we 
disagree on how the value of "args" above would respond to whatever "+" 
expands to.  (Unless the disagreement is moved to a disagreement on what "+" 
expands to, which no one would like.)


                                    VLS & HTTPY


I think it would be great to separate out the VLS ideas into a separate 
HTTPY (or whatever we call it) service.  Steve Jenson has expressed an 
interest in reviving the VLS, and we've talked some about how a revived VLS 
should deal with Firewalls, NATs, delayed lookup, and activation.  Steve, 
you should take a look at some of the old messages about the httpy 
proposals.  Anyone have some thread root URLs for Steve?  Or URLs of key 
messages?


        Cheers,
        --MarkM