Lists, Sets, and Associations

Bill Frantz frantz@communities.com
Wed, 14 Oct 1998 12:35:21 -0700


At 12:19 PM 10/14/98 -0700, Mark S. Miller wrote:
>At 09:36 AM 10/13/98 -0800, Bill Frantz wrote:
>>I would prefer a syntax which permitted several different implementations
>>of these abstractions.  Lists can be implemented with arrays or linked
>>lists for example.  Different uses will find that one implementation is
>>better than another.
>
>Feel free to suggest one.
>
>E's use-syntax already has this property -- this is why operators simply
>expand to messages.  E's construction syntax invokes one specific
>construction function, and this same issue appears in literals.  For
>example, in any language with multiple numeric data types, the literal "3"
>evaluates to an instance of one of these (with Java & E making different
>choices).  However, I find 
>
>	altList([1, 2, 3])
>
>an adequately pleasant construction expression for alternate implementations.

I tend to avoid syntax discussions since I don't understand computation
thru language, but rather thru unfolding action which is somewhat language
independent.  However, I also find the above construction adequately
pleasant for specifying an alternate implementation.

How does it expand into an invocation or series of invocations?

>
>Finally, E's pattern syntax is defined to (but not yet implemented to)
>interact with the specimen only by messages, so a tuple-pattern should be
>perfectly happy to match against any object that behaves as a tuple.
>
>
>	Asyncronously, more, in non-deterministic order, later,
>	--MarkM
>
>