[E-Lang] hydro

[Marc Stiegler]

> I'll respond to the rest of this later, but I couldn't resist this bit
> right away. You do of course realize that you've already trusted me to
> add strong encryption to E. I can't think of any area that could be
> more crucial to security. The .class files in e-patch.jar that you
> sourced from me have far more ability to compromise your security that
> my collection classes do.

True enough. And I "feel" trust for your e-patch.jar, and yet "feel" a
requirement for review of Hydro. So what is going on here, am I just
irrational, or is there actually some sort of logic underneath this?

I think the issue is, as stated not quite articulately enough earlier,
architecture versus code. I have assumed that your epatch didn't have any
architecture implications that might bubble up to changes in the E
programmer level (i.e., would not require modifying Walnut if something were
wrong). For the same reason, I trust Hydro to the extent of documenting it,
and using it in examples, in Walnut, as a library package. It is when these
structures get their own shorthands that are permanent parts of E syntax
that I am driven to desire a review by someone like dean. As I think about
it, even markm's stuff usually gets reviewed when it is an architectural
change of this nature (usually by me myself, and often by the entire list
:-). Viewed this way, I am actually just requesting (well, kinda demanding)
the level of scrutiny markm has to put up with (though he generally
volunteers to do so, and I would guess you would be happy with it too if it
could be done in a timely fashion :-)

So I will highlight here a comment I made in passing in the last email. The
review I'd need in order to feel comfortable with Hydro only needs to
address questions that could bubble up and bite E programmers in the
shortcuts, presuming that lower-level flaws (if any) could be dealt with
another day. Uh, this assumes the dean/markm-like reviewer agreed that this
was a reasonable basis for review. Assuming that, the review may be much
less burden, and perhaps would only focus on the part of the Hydro API
that is visible to "normal" programmers. Identifying the parts of the
Hydro interface that was for "users" as opposed to the parts that were
for Hydro developers was actually a general difficulty I had last time
I encountered Hydro, though you were able to walk me straightforwardly
through the process of getting what I wanted out of it.

I am talking on and on about this to see if, given these qualifiers, the
problem is lightweight enough that dean can "properly" review it; it does
still require a posting of a full syntax proposal. Also, documentation of
the
"user's interface" that is better than what was available when I looked at
it so long ago would make it much more likely we could get dean
or someone like dean to review it in their spare time.

I am also assuming that changing Hydro as the underpinning structure would
add no problems with upward-compatibility-across-E-versions that List/Maps
do not already introduce; this is another assumption for markm to check, or
the reviewer to review.


--marcs