[E-Lang] An Attempted Restatement of Hydro's Semantics

[Marc Stiegler]

> I don't think indexing is useful, but if you really want it, then I would
> be willing to add it to the Initializer interface. Note that here again,
> E's tuple break out syntax is much more powerful. For example:
>
>      def [ first, second, third ] := results
>

...and...

> >An indexable list is one of the first tools a programmer will reach for.
It
> >must be there.  We'll already surprise them enough when they find out it
> >must be immutable.
>
> I know MarcS has said this before too, but he's never shown a plausible
> example. E's for loop really obviates the need for index operations.

Having belatedly observed that the E programmer can always fall back upon
Java collection types, I have opened myself to arguments for radical
departures from conventional programming notions. Having arrived in this
very different headspace, I now examine Tyler's arguments on their other
merits rather than on their backward-compatibility-with-human-expectations
features, and I come to an amusing, even astonishing (to me) conclusion:
Tyler seems to be correct about not needing indexability.  It is not just
the for...loop by itself that gets you there, however (as Tyler noted
correctly elsewhere, though perhaps not in quite the unified fashion I am
about to present it). It is the following combination of features that, when
you have absolutely all of them, seems to get you complete eradication of
the index (for unsorted lists):

for each in list
def [a,b,c] := list
getHead(list)
getTail(list)

Looking at this from a theory perspective (wo, big mistake, me trying to
talk from a theory perspective...here goes anyway), what are the
circumstances under which the programmer has enough information to
meaningfully reach inside an array and pick an element?

Well, the first and last elements are special, so you sometimes reach for
them with list[0] and list[size-1]. But this is covered by getHead/getTail

A middle element can be special if the list has been specially constructed
to contain a specific number of elements at carefully specified positions,
in which case you would want to "unload" them into elements with better
names (this is usually a terrible programming practice of course, and is
rarely necessary in modern languages...though I do use it in E in the
limited context of returning pairs the way BrandMaker and PromiseMaker do).
This is covered by E's breakout syntax.

Finally, if the middle elements are not special, the only meaningful way to
reach them is through iteration.

For sorted lists, there are additional search/retrieve operations for which
the index can be useful, but I suspect those are all covered with other
features in Hydro that I haven't looked at, since I haven't looked at sorted
things in Hydro :-)

Fascinating. And, if it is really easy to put an indexing function into the
system, I would still recommend including it, even though no one ever uses
it and even though novice E programmers have the Java collections to fall
back on (I just can't get off my human-expectations hobbyhorse, apparently
:-) I am not fierce about this, however, so if others conclude it is okay
without indexing, I'm cool.

--marcs