[E-Lang] Collection syntax ideas

[Dean Tribble]

I'm going to list various (possibly contradictory) collection-related 
thoughts that have not yet gelled into a proposal, in the hopes of 
provoking other people.  These are part of an attempt to simultaneously 
solve several problems:

- Integrating external collection libraries smoothly.  Usually, syntactic 
support for creation typically makes some types easy to create, and others 
difficult.

- Without some mutable object, Accumulation is difficult or 
expensive.  StringBuffers provide accumulation support for immutable strings.

- The creation syntax does not mesh with the variant creation syntax.

- Syntactic support for collections should be integrated with quasi-literal 
support.

33) With a sufficiently rich creation syntax, variant creation could be 
just a simple quasi literal:  [map, key => value, othermap] could create a 
map from two other maps and a key-value pair.  Note that the syntax is 
substantially more expressive than just message sending because it easily 
expresses adding multiple values.

34) Collection literal expressions should support proving an optional 
collection maker, in the same way that quasiliteral strings do (e.g., 
`hello, $name` or e`$world hello`).  For example, SplayMap[k1 => v1, k2 => 
v2, othermap] is like that above literal creation, but with my own maker 
provided.

34a) The default maker should be named in the style of uriGetters, allowing 
an implementation or package to by default use another implementation.  For 
example,  'def Map__maker := <import:hydro.MapMaker> or some such.

35) Immutable collections could implement the protocol for a collection 
factory, thus unifying literal creation and variant creation.  map[k=>v] is 
just asking 'map' to construct a new instance with the following literal 
map data.  (Yes, this in some ways contradicts 33, and reveals something 
important:  the syntax in 33 does not have a way to determine the 
implementation for the resulting collection, whereas this does).

36) For each interesting type of collection, there would be a collection 
maker type that could accumulate elements into the collection, and return 
snapshots of the built collection.  This would be the StringBuffer to the 
immutable collection's String.  This taps into the main place right now 
that people actually get trained in and understand the distinction and value.

37) The operations on a collection maker would include add(k,v), 
addAll(map), etc.  Literals would expand to create the appropriate maker 
instance, invoke the above methods to construct the instance, and extract 
it.  However, that same maker could instead be used explicitly (just as 
StringBuffer can) for accumulation; for example, if the elements are 
generated within a loop.  It's this last advantage that makes me prefer 
generating code to having a quasi parser parse a string (though that to is 
perfectly possible).

38) Disallow storage of 'null' as either keys or values of Maps.  This then 
allows map[k => ] to straightforwardly represent map without the key.

39)  All of the above expressions have assumed no support for 
Update.  Thus, Update would be:
	map := map[key=>value, otherMap]

40) To make a consistent syntax between maps and lists for when an element 
should be expanded in place, use '...' after the collection to be 
expanded.  Thus, the above example would be:
	map := map[key=>value, otherMap...]
This is unfortunately inconsistent with strings, but so nice to read....

41) Very abstract idea:  Immutable collections correspond to Editions in 
Xanadu.  The mutable variables referring to a collection would be a Work, 
which can be changed to point at a new Edition.  This suggests looking at 
the Slot as a Work, and thinking about what would like to do with it.  An 
example might be considering the "+=" ilk or operation to be an operation 
on the Slot (as MarkM sent in his message).

More later.
dean