[mercury-users] Another indexing proposal (was mercury websit e (was Suggestion: new operator))

[Ralph Becket]

>From schachte at cs.mu.OZ.AU on 20/10/2000 10:24:03
> 
> An alternative which is in some ways preferable is parentheses:
> 
>     1.  It makes good sense to think of at least maps and arrays, and
>         maybe strings as well, as functions which can be applied to an
>         index.
> 
>     2.  Mercury already understands Variable(Arguments) syntax.
> 
>     3.  FORTRAN uses parentheses for array indexing.  We do want to be
>         compatible with FORTRAN, don't we? :-)
> 
> The only catch is that, of course, you can't apply a data value to some
> arguments.  It currently doesn't make sense, but that could be changed.
> The syntax for declaring a type could be extended to allow the user to
> somehow define what expression should be evaluated when a variable of
> that type is applied to arguments.

This isn't quite right.  You *can* apply a value to arguments provided that
value is a function (the higher order syntax was changed a few months ago).

While it's appealing to think of mapping types as functions from keys to
values, there are many other operations one can perform on them,
so this functional view is somewhat misleading.  Also, it's arguable
whether, say, strings should be viewed as mapping types at all.

> For concreteness, here's a simple proposal.  Like the "where equality
> is ..." suffix on type declarations, Mercury would allow "where
> application is...".  For example:
> 
> 	:- type map(K,V) ---> ...
> 		where application is map__lookup.

I really don't like your suggestion for the reason that it (a) requires
the programmer to be much more careful when parsing higher order code ("is
it an application or some sort of lookup operation?"), (b) by the same
token it makes the compiler more complex, (c) requires a non-trivial 
change to the language and compiler, and (d) all this for what amounts to
a little syntactic sugar that - in a different albeit no less concise form -
can be achieved with no change to the language or compiler by introducing
the
`@' convention.

Ralph

p.s. Okay, we might need to add a line to ops.m

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------