Generalizing the E operator expansions

[Tyler Close]

Markm wrote:
> At 06:31 AM 8/26/00 , Tyler Close wrote:
> >I've updated Hydro to support the partial order
> definitions that Markm
> >defined, as well as the hashtable equivalence behaviour that Dan
> >Bornstein suggested. The new version, Beta3, can be found at:
> >http://www.waterken.com/Hydro/2.0/
> >[...]
> >There are a few more things that need to be done in order to fully
> >integrate Hydro into E. One of those is operator support.
>
> This is great news.  But...
>
> There are a number of other issues as well, such as

Yes, as I tried to indicate, these operators just seemed like another
separable chunk that could be discussed. I was expecting more issues,
though not necessarily these ones.

> * Hydro's use of purely abstract classes rather than
> interfaces.  Note:
>    Considered only as a Java API, I like Tyler's choice.
> However, while E
>    objects may in-effect implement Java interfaces (from
> the point of view of
>    pre-existing conventional Java clients of those
> interfaces), E objects
>    cannot in-effect subclass Java classes.

Ooooh... ouch. I can see that getting white box inheritance to work
smoothly would be tricky, but a pure abstract class is really no
different than an interface. Do you just not distinguish between the
two in the current implementation?

> * There are many other naming mismatches such as "iterate"
> vs "inspect" (and
>    in that context, "evaluate" vs "run").
>
> * I think there are also several semantics issues.  For
> example, on a brief
>    skim, it seems in the previous discussion of equality
> that Tyler thought I
>    was referring to one the Java equalities, all of which
> are broken, rather
>    than to E's equality (or "sameness").  OTOH, for Hydro
> to be a standalone
>    library, it can hardly use E's sameness as the default
> unless we move the
>    sameness code from E to Hydro.

I was expecting E to provide its "sameness" equality as an
implementation of Equivalence and then to provide its own Factory
object for constructing Maps and Sets. I am not expecting my Hashtable
class, or any of the other "implementation" classes, to be directly
exposed to the E programmer. The E programmer should only ever have
access to containers of type: Queue, Set, Map, SortedMap, SortedSet.

> Nevertheless, this is indeed great news!  Good job Tyler!

Thanks. I look forward to having an E language wrapper for my code.

Tyler


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com