[m-dev.] Reopened: state vars syntax sugar

Peter Schachte schachte at csse.unimelb.edu.au
Wed Jan 31 14:35:45 AEDT 2007


Gregory James DUCK wrote:

> See my previous email, where I defined:
> 
> output(Inst >> _) = free >> Inst
> 
> and !Mode is shorthand for (Mode, output(Mode)), therefore:
> 
> !out = (out, free >> free)  = (out,unused)
> !uo  = (uo,  free >> free)  = (uo, unused)
> !(bound(a;b;c)>>bound(a;b)) = (bound(a;b;c)>>bound(a;b),free>>bound(a;b;c))
> 
> No semantic errors, but not very useful either.

OK, makes sense.  So you'd pretty much always use Inst>>Inst modes with this,
with the exception of unique>>dead.  It's nice that your rule handles
uniqueness without extra rules.

I like this proposal a lot better than what Julien is advocating, as it
simplifies both types and modes, where Julien's scheme only saves you repeating
1 type.  But I still like using an inst better,  because I find it simpler to
think of the desired inst of the state variable than to think about the mode of
the first of the two arguments that will be added for the state variable.

>>> I like this syntax mainly because it is concise (which is surely one of the
>>> main reasons for introducing syntactic sugar).  The only funny thing is
>>> understanding that !di or !in also an "out" mode as well
>> It's a lot better than !Type::(Mode1, Mode2), but it's not any more concise
>> than !Inst.
> 
> That's not quite true simply because the standard inst names
> (e.g. ground,unique,etc.) seem to be longer than the standard mode names
> (e.g. in,uo,etc.).

Ah, that's just because insts aren't used much.  Put this in builtins.m:

	:- inst g == ground.
	:- inst u == unique.

OK, problem fixed.  !g is shorter than !in.  ;-)

-- 
Peter Schachte              The government of the United States is not, in
schachte at cs.mu.OZ.AU        any sense, founded on the Christian religion.
www.cs.mu.oz.au/~schachte/      -- George Washington, 1796
Phone: +61 3 8344 1338
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list