[E-Lang] Collection syntax ideas
Mon, 26 Mar 2001 11:13:35 -0800
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.
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
> -----Original Message-----
> From: Dean Tribble [mailto:firstname.lastname@example.org]
> Sent: Monday, March 26, 2001 12:11 AM
> To: email@example.com
> 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
> solve several problems:
> - Integrating external collection libraries smoothly.
> Usually, syntactic
> support for creation typically makes some types easy to
> create, and others
> - The creation syntax does not mesh with the variant creation syntax.
> - Syntactic support for collections should be integrated with
> 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
> 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
> 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
> 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.
> e-lang mailing list