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

[Tyler Close]

At 08:08 AM 4/2/01 -0700, Mark S. Miller wrote:
>In the union of two such multi collections, even a full ordering function
>would not determine the resulting order.  You must use creation order to
>deterministically decide whether the result is
>[ "MarkM", "markm" ] or [ "markm", "MarkM" ].

For a unique set:

     [ "MarkM" ] | [ "markm" ] == [ "MarkM" ]

For a replace set:

     [ "MarkM" ] | [ "markm" ] == [ "markm" ]

For a multiset:

     [ "MarkM" ] | [ "markm" ] == [ "MarkM" ]

and

     [ "MarkM", "mARKm" ] | [ "markm" ] == [ "MarkM", "mARKm" ]

and

     [ "MarkM" ] | [ "markm", "mARKm" ] == [ "MarkM", "mARKm" ]

>You might want to consider instead an immutable variant of what I do in E's
>current mutable collections.  All my update operations which might have a
>conflict have an optional additional argument called "strict", which
>defaults to false.  If provided and true, then the update operation throws
>an exception rather than replacing.  The knowledge that a replace would be
>an error is per-operation, not per-collection.

I've never found this to be true. Do you have an example?




> >>[...] I don't think there's enough need for a multimap to justify 
> keeping it.
> >
> >I also use the multimap a lot. An example of this can also be found by
> >looking at an upcoming revision of my SLS proposal. Rather than just
> >providing a string list, the SLS should provide a multimap of string 
> type =>
> >string. This will allow for the storage of heterogenous information in the
> >SLS. For example, the string type might be "url", or "onion", or ...
>
>I find "a lot" surprising.  I'm not surprised that there are occasional
>examples like the SLS.  However, if these are comparatively rare, I'd be
>inclined to use a map whose values were sets, rather than learn a new
>abstraction for a rare usage with no clear benefit.  Sorta like Dean's
>argument against rarely used syntax.

A review of my code suggests that the multimap may actually be the most 
popular type of map.

Most of the code I have right now is for a B2B trading platform. In lots of 
different places, objects keep a sorted map of records for the trades they 
have engaged in. The key in this multimap is the date. Many objects keep a 
record of who they've had trades with. The key in this multimap is the 
identity of the counterparty.

Another common theme is keeping a multimap of [ type indicator => cap ]. I 
think this happens a lot since remote caps start out life as deferred, but 
I want to dump them into a map right away.

Wherever there's an option list in the GUI, it seems to be derived from a 
multimap. The key selects what the possible valid entries are and the 
option list is to let the user select the specific cap to be used.

So basically, I find that you are surprised very surprising. ;)


>I would like to define a reduced subset of Hydro, adequate for all core E
>language collection needs.  I would like the E language to specify only this
>subset as its necessary collection API.  Having the rest of Hydro available
>as libraries is fine, just as it is fine for a zillion other libraries to be
>available.

I don't want to have to jump through hoops to construct a sorted map, so 
please don't make me. The whole point of the Initializer class is to put 
the collection classes that I need at my fingertips. Why do you want to 
push them away from me?

Note that other libraries are more than welcome to provide alternative 
Initializer implementations (in fact, I've got a couple).


>I continue to think that the core collection types may only need to be
>
>     unsorted
>         * map
>         * set
>         * list/multiset
>             * the list subtype String
>
>     sorted
>         * map
>         * set
>         * list/multiset
>
>     * Domains/Regions or something (not yet thought about)
>
>On reflection, the 3 sorted types above probably don't need to be included
>in this core subset, leaving us with 5.  If we can define the API of the
>core subset so it doesn't pull in others, ie, so it's self contained, then
>we won't need to argue about the rest of Hydro in order to for E to shift
>from its current collections to this subset of Hydro.

Huh? What else is there to Hydro other than these collection types: [ 
Queue, Set, Map, SortedSet, SortedMap ]? These are what you listed.

Tyler