[m-dev.] Syntactic sugar for functor matching

[Peter Schachte]

On Fri, Nov 02, 2001 at 03:11:19PM +1100, Fergus Henderson wrote:
> 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),
> 		...

I never liked that very much, either, for the same reason.  But I can cope.

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

Hang on.  It'd actually be

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

which doesn't seem so confusing to me because the square brackets make it
clear the context is different.

> > > Another variation is that we could also allow field syntax with terms
> > > built using `()':
> > > 
> > > 	con(whatever(Something), ^name3=Foo, ^name2=_, ^name4=_)
> >
> > 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.

This is really my main point.  You're proposing to change the meaning of the
basic, standard term notation; I'm just proposing to give a meaning to
something that is now a syntax error.

Your proposal gets this whole cognative dissonance thing happening for me:
parentheses tell me it's an ordinary (positional notation) term, but half
way into the thing the ^ tells me no, it's something else.  With square
brackets, once you see the "functor" on the front immediately followed by a
square bracket, you know to look for named arguments.  There's some
redundancy to help you.  With parentheses, it's only when you find the named
arguments that you know.  I just find it confusing, like the ground is
moving under my feet.

What's the argument for using parentheses?  And aside from confusing object
and meta in discussions, what's wrong with "..."?

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

Because you can't currently change multiple arguments at once.  If there are
some validity constraints on a constructor, it's not in general possible to
make the changes one at a time; they must be done simultaneously.

That's not a major point, and I'd certainly argue against the above proposal
as too complicated.  But if some simple generalization of whatever is chosen
allows it, it would be nice to have.

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