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

[Tyler Close]

MarkM wrote:
> 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".

Sorry, you're right, this was an inflammatory way to state this.

> 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.

My point is that you can go even further. A capability based
collection library is something that could have been packaged up and
announced separately. It might even have prevented the existence of
the Java Collection API.

>  However, as with Hydro & Droplets, they evolved
> together to play
> well together.

For example, Droplets does not use the container implementations in
Hydro. Droplets does use the container interfaces defined by Hydro,
but it uses different implementations that take advantage of Acid to
scale to very large sizes. Acid also uses a different implementation
of equality than is implemented in Hydro. A lot of work was done to
make sure that Hydro on its own was a complete and compelling product.
So yes, Hydro does play nicely with Acid and Droplets, but that was
achieved by making a very flexible interface and doing a little extra
work on both sides. I don't think E has taken the same design
approach.

I think there are a number of different products that go into making
E. I think it would be very worthwhile to package these up separately
to that they can start winning market share. Doing this would prevent
managers (MarcS) from worrying about ship dates.

> Btw, ELib is separable, and can be shipped and used
> separately from the E
> language.

ELib is itself separable into even smaller chunks. Some of these
chunks are ready to be very stable and others are not. For those
stable chunks that can be made into independent products, there is an
opportunity to start building a user base. For example, if we could
all agree on Hydro for use in E code and Java code, then we could
start building an E developer community around just this one small
chunk. I write real applications using Hydro in Java. I feel that this
is leading up to a switch to E. We could give this experience to
others.

> 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.

Yes, this is the sort of parallelism I am thinking about. Again, sorry
for boxing you into a corner.

> 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.

I would say that "args" does not respond to the "+" operator. I think
"args" should be an instance of
com.waterken.canal.source.initializer.Initializer. You can only give
"+" a definition once you have decided on the type of collection that
you have. Therefore, to append another argument, you could write:

	args := args toFIFO()
	args += "another arg"

or, to prepend another argument, you would write:

	args := args toLIFO()
	args += "another arg"

>                                     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.

I think it would be good if this discussion moved onto the e-lang
list. I imagine that Mojo Nation also needs/uses a DNS replacement
(Zooko?). If there were a consensus amoung E, Mojo, Droplets, Steve's
needs, etc. around what the VLS should be, then such a generally
useful product could get significant market share.

My own e-lang archive only goes back to the 27th of July, so my HTTPY
proposal happened sometime before that.

Tyler