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
>
>