[mercury-users] Syntactic sugar for higher order types and modes

[Tyson Dowd]

On 21-Jul-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 21-Jul-2000, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > On 20-Jul-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > I like the idea, but not the particular syntax that you've chosen for it.
> > 
> > The usual rule about this is that if you don't like syntax you're not
> > supposed to criticize it until you come up with a better suggestion.
> 
> I'm not sure where you heard that rule ;-)  But if you insist,
> I can always fall back to just suggesting that we stick with the
> current status quo, which is IMHO better than adding the feature that
> Ralph suggested with the syntax that he suggested.

Damn, you escaped that one too easily.

> 
> However, I do have another suggestion:
> 
> 	- change the module qualifier from `:' to `.' as previously planned
> 
> 	- use infix `:' in `pred' and `func' declarations:
> 
> 		:- type bar == pred(int, int).
> 		:- type baz == (func(int) = int).
> 
> 		:- pred foo1 : bar.
> 
> 		:- func foo2 : baz.

This would be good, `:' as type qualifier.

> 
> 	- I guess we could also use infix `:' in `mode' declarations...
> 
> 		:- inst bar_mode1 == (pred(in, out) is det).
> 		:- inst bar_mode2 == (pred(out, in) is nondet).
> 		:- inst baz_mode == (func(in) = out is det).

Bzzt.  :- inst uses `=' not `==' (but see below for a more sane syntax).

> 
> 		:- mode foo1 : bar_mode1.
> 		:- mode foo1 : bar_mode2.
> 
> 		:- mode foo2 : baz_mode.
> 
> 	  On the other hand, this is not so nice, since the idea was
> 	  to use `:' as a type qualifier, and here in mode declarations
> 	  it's a mode qualifier.  On the other hand using `::' wouldn't
> 	  be very nice either, since the syntax `:- mode foo :: bar.'
> 	  already has a meaning.  Hmm, I guess we could use `:::'.

Ah backwards compatibility.  I suggest we largely ignore it ;-)
Backwards compatibility flags for those who need it, miniature american
flags for those that don't.  (Simpsons gag).

The problem is really that :- mode is overloaded to both declare the
mode of a predicate, and to define modes.  We want to be able to tell
these things apart.  We want `::' to mean mode qualification, not mode
definition.

Defining a mode should be done using  ==

	:- mode foo == inst1 -> inst2.

Same with insts.

	:- inst inst1 == someinst.

Now you can use : to type qualify, and :: to mode qualify.


Yes, this will break code.  But if you're changing the module qualifier,
you might as well go the whole hog and fix this syntax too.
I suspect a backwards compatibility flags could handle "legacy" code.
Probably the easiest thing to do is write a filter that turns old syntax
into new.


> 
> Note that for mode declarations like this, you should really specify
> the name of a higher-order inst, not a higher-order mode.
> 
> > My suggestion is no operator at all.
> > 
> > :- pred foo bar.
> >
> > This is completely the same as the syntax for predicate types (and
> > modes) and is how we use equivalence types everywhere else (no special
> > operators or syntax, just use the equivalence wherever you would
> > normally put the equivalent type).
> 
> Well, it's not really the same as the existing syntax for
> predicate types and modes; if the current syntax were
> 
> 	:- pred foo1 pred(int, int).
> 	:- func foo2 (func(int) = int).
> 
> then what you suggest would make perfect sense, but the current syntax
> is a little different than that, so it's not "completely the same".

Yep, that's true.

I'm actually leaning towards your syntax, because it cleans up a lot of
things that are bugging me about Mercury syntax.

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