[E-Lang] Immutable map operations

[Tyler Close]

Dean wrote:
> > > >All of the comparison operators ( < <= <=> >= > ) have
> meaningful
> > > >operations for maps.
> > >
> > > Since their meaning does not leap out at me, perhaps you
> > > could elucidate (a pointer to a description would be
> sufficient).
> >
> >"http://www.waterken.com/Hydro/2.0/doc/com/waterken/canal/s
> tore/collection/Map.html#compareTo(java.lang.Object)"
>
> Since that's defined by "difference", whose definition for
> collections I
> could not find, it's not even clear to me what that answer
> is for Hydro's
> Maps.

On that very same Javadoc page is the definition of the mask() and
xor() methods. These methods calculate the difference and symmetric
difference. I've turned these words into hyperlinks to the
corresponding methods for the next release of the Hydro docs.

> > > >All of the set operations ( | & ^ ~ ) have meaninful
> operations for
> > > >maps. Some of these are the same as your "b) Variant"
> > > operations. "|"
> > > >is the same as "withAll", "& ~" is the same as "withoutAll".
>
> Only if you are willing to ignore the values of one or both of the
> maps.  That means they are not set operations anymore, and all the
> mathematical assumptions no longer hold up.  For example,
> the following are
> no longer true: ~~X == X, (X & ~Y) | Y == X | Y, X & Y == Y
> & X, etc.  If
> sometimes the argument is a Map and sometimes a Set, then I
> would be even
> more confused by the contract.
>
> It seems like the real contract for Maps is not what sets
> do, but is just
> close enough that it could be wedged into the convenient
> punctuation, and
> we have to agree to ignore the problems.  This feels like
> an artifact of
> under-specified contracts.  It typically results either
> from multiple
> inheritance (interface inheritance as well as
> implementation inheritance)
> or text-match method naming as in E.  In E, there is no
> contract for "&",
> it's just a string.  There's no place to document that the
> associated
> implementation is associative or commutative or supports basic
> set-theoretic axioms.  But those guarantees are important,
> and I would much
> rather have assurance that they held for sets, regions, functions,
> bitvectors, etc. than have other semantics wedged into them
> to leverage the
> syntax.

....

> It sounds like you are talking about sets, where I was
> talking about
> Maps.  If so, please revisit just thinking about Maps
> because I mostly
> agree on Sets.  Maps are not collections of objects, they are keyed
> collections of objects, and my understanding of the Hydro
> proposal is that
> it would treat only the keys as a set, and the values would
> go along for
> the ride.

I don't think maps and sets are all that different. Your understanding
of the Hydro proposal, that "maps are sets where a value comes along
for the ride", is correct. This isn't completely unheard of and is in
fact exactly what the C++ STL does. Maybe you could write out a simple
example of some code that produces surprising results.

> >Take
> >a step back and look at the way you work with the
> immutables that are
> >already in the language: the integer / bitfield, the string, the
> >character. All the way back to C, people have been happily
> using these
> >immutables. My syntax proposal comes from trying to make
> collections
> >have the same "look and feel" as these other immutables.
>
> All the immutables you named have scalars as their
> elements, all of which
> conform to well understood mathematical properties, axioms, etc.

How is it that you can call a bitfield or a string a scalar? Both
bitfields and strings could be mutable collections, but instead are
modeled as immutable collections. Where has there been mathematical
study of the properties of text strings?

Tyler