[m-dev.] Syntactic sugar for functor matching

[Fergus Henderson]

On 02-Nov-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> 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.

Well, that's like our DCG field access syntax:

	foo -->
		^name3 = Foo,
		^name1 = whatever(Something),
		...

> How about using :: instead of = (ie, make it look more like the declaration,
> rather than accesses)?
> 
> 	con[name3::Foo, name1::whatever(Something)]

I don't think that is a good idea.
It is too similar to the use of `::' as mode qualifier.
For example, you might want to write

	foo(X::in, Y::out) :-
		bar(field1::X, field2::Y).

where here the first two `::' would be mode qualifiers
and the second two would be field name specifiers.

> > However, something that might make more sense would be to allow
> > unnamed arguments, provided that all the unnamed arguments
> > precede all the named arguments.
> 
> It looks a little confusing to me.

Well, that's the second negative comment on this --
I'm happy to drop this idea (at least for now ;-).

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

It's not 100% backwards compatible, but I think it is compatible enough.
The only incompatibility would be if someone was using '='/2 as a data
constructor, and I think that is rare enough that we don't need to worry
about it.

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

If you want the syntax to stand out, then using `^'
as I suggested should IMHO be enough.

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

If you want better syntax for that, I'd rather something like

	OldFoo{^name3 := Foo, ^name1 := whatever(Something)}

But this is about the point where I start drawing the line:
we already have a syntax for that, so why add another one?

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