[m-dev.] Syntactic sugar for functor matching

Fergus Henderson fjh at cs.mu.OZ.AU
Thu Nov 1 21:02:09 AEDT 2001


On 01-Nov-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> Modify the Mercury reader to accept terms like:
> 
> 	con[name3=Foo, name1=whatever(Something)]

I very much like that idea.

One possible variation: to make the syntax more "field-like",
the field names could be prefixed with `^':

 	con[^name3=Foo, ^name1=whatever(Something)]

Personally I think this makes the meaning a little clearer.

> Ralph's example could be written:
> 
> 	p(constructor1[], ...) :- ...
> 	p(constructor2[], ...) :- ...
> 	p(constructor3[], ...) :- ...
> 	p(constructor4[], ...) :- ...

I like this better than my earlier suggestions `ctor(___)' and `ctor(...)'.

> con would have to be a constructor with named arguments.

You could even generalize this to unnamed arguments, by allowing
numbers as well as names, with all arguments being sequentially,
starting from 1.  This style is supported by the feature terms
in the language LIFE.  In Mercury with Peter's proposed [] syntax
extension it would look something like this:

	con[3=Foo, 1=whatever(Something)]

But I'm not sure that this would be a good idea, though.
In fact the more I think about it the less attractive it seems ;-)

-----

However, something that might make more sense would be to allow
unnamed arguments, provided that all the unnamed arguments
precede all the named arguments.  This style is supported by Ada.
In Mercury it would look like this:

	con[whatever(Something), ^name3=Foo]

This would be equivalent to
	
	con(whatever(Something), _, Foo, _)

This extension would be nice to have, but is certainly not essential.

-----

Another variation is that we could also allow field syntax with terms
built using `()':

	con(whatever(Something), ^name3=Foo, ^name2=_, ^name4=_)

The only difference between `foo(...)' and `foo[...]' then would be that
for `foo(...)' you always need to supply all the arguments, whereas for
`foo[...]' any arguments that you don't supply are assumed to be anonymous
variables (`_').

This would be nice because it would mean that you could call constructors
using named field syntax and still be sure that you had mentioned every
field.  For example, if we want to use this notation for predicate or
function calls with named arguments, then you'd almost always want to
use the `foo(...)' notation rather than the `foo[...]' notation.

I think this extension would be pretty important.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list