[m-dev.] Syntactic sugar for functor matching

Peter Schachte schachte at cs.mu.OZ.AU
Fri Nov 2 14:40:35 AEDT 2001


On Thu, Nov 01, 2001 at 09:02:09PM +1100, Fergus Henderson wrote:

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

The ^ looks kind of odd to me hanging off on the left there like that.  How
about using :: instead of = (ie, make it look more like the declaration,
rather than accesses)?

	con[name3::Foo, name1::whatever(Something)]

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

It looks a little confusing to me.  The idea that some of the elements
between the brackets are terms and some are name=term or name::term pairs
somehow makes it seem less clean.  I suppose you could generalize the original idea to allow

	con(whatever(Something))[name3::Foo]

so the bracketed thing is a kind of modifier you can put after a term to add
some arguments to it.  But I think it's probably better to just tell people
to name their arguments.

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

I agree it is important to give some way to indicate that you mean to
specify all arguments to the term, and another way to indicate that
arguments not explicitly specified should be unique variables.  But I don't
like this syntax because it's not backward compatible anymore, and because I
think it confuses terms in general.  One nice feature of the proposal to use
square brackets is that they stand out, so you won't tend to mistake it for
an ordinary (positional) term.

I considered suggesting using braces where all arguments are to be
specified, but in many fonts they really look too much like parentheses.

How about this:  you always need to specify all arguments, unless the last
element of the list of members is '...'.  So if you write

	foo[name3::Foo, name1::whatever(Something)]

then foo must be a constructor with two arguments named name1 and name3.  If
you want to default unmentioned arguments, you would write

	foo[name3::Foo, name1::whatever(Something), ...]

Then Ralph's example becomes

	p(constructor1[...], ...) :- ...
	p(constructor2[...], ...) :- ...
	p(constructor3[...], ...) :- ...
	p(constructor4[...], ...) :- ...

Where the first elipsis on each line is meant literally, and the other two
are not.  Hmmm.  I see Fergus' earlier point about ... making meta
discussions harder, but ___ doesn't look natural to me.

----------------

One other feature that would be useful would be to allow you to specify that
defaults for unnamed arguments should be taken from another term.  I know
the := syntax gives a way to do this, so it's not essential, but it still
seems like a natural thing, and it may be a bit nicer when setting multiple
arguments.  I can't think of a syntax I really like for this, but maybe
something like:

	foo[name3::Foo, name1::whatever(Something), ...OldFoo]

would denote the term identical to OldFoo, except that name3 is Foo and
name1 is whatever(Something).  Ie, it's the same as

	(OldFoo^name3 := Foo)^name1 := whatever(Something)

-- 
Peter Schachte              The Street finds its own uses for technology.
schachte at cs.mu.OZ.AU            -- William Gibson 
www.cs.mu.oz.au/~schachte/  
Phone: +61 3 8344 9166      
--------------------------------------------------------------------------
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