[E-Lang] Collection syntax ideas

[Karp, Alan]

Dean Tribble wrote:
> 
> - Without some mutable object, Accumulation is difficult or 
> expensive.  StringBuffers provide accumulation support for 
> immutable strings.
> 

The Sisal team found they could get excellent performance using specialized
compiler optimizations.  I've tried to get more detail, but all the links,
including e-email, from the main page appear to be dead.  I'm still trying
to find these folks.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Dean Tribble [mailto:tribble@e-dean.com]
> Sent: Monday, March 26, 2001 12:11 AM
> To: e-lang@eros-os.org
> Subject: [E-Lang] Collection syntax ideas
> 
> 
> 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.
> - 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
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>