[m-dev.] syntactic suggar suggestion for state variables

[Mark Brown]

On 14-Jan-2007, Ben Schmidt <b.schmidt at ugrad.unimelb.edu.au> wrote:
> On 13-Jan-2007, Peter Hawkins <hawkinsp at cs.stanford.edu> wrote:
> >What about something more like
> >:- pred p(mysvtype::!(ground)) is det.
> >
> >i.e. the argument is an inst, not a mode, so !(I) means in(I), out(I).

I think this is the right approach.  We should aim to parameterise these
modes with inst information (i.e., subtype information and uniqueness
information).

Furthermore, the fact that "mode" !I would expand out to two mode arguments
is consistent with what happens with clause arguments.

> I don't like that one, because it complicates doing things with unique 
> modes rather than normal modes (in!out, ui!uo and di!uo could all be 
> quite common to use what is now my preferred syntax :-)).

I was going to make the same observation, but you beat me to it.

However, I think the real problem is that the way insts are expressed in
Mercury's existing mode system does not allow the uniqueness to be easily
parameterised.  We would all recognise that modes `di, uo' are like a
unique version of `in, out', but if you look at the insts involved:

	unique >> dead, free >> unique
vs
	ground >> ground, free >> ground
	
then there is no simple way to factor out the uniqueness component of the
insts.  That is, there is no way to write mode arguments `in(U), out(U)'
where U could be either ground or unique, and get the expected result.

We need to think about the relationship between the three components of
insts (free-/ground-ness, uniqueness, subtypes) before going too much
further with this discussion about mode of state variables, IMHO.  Also,
it is way too early to start talking about concrete syntax (which operator
to use, etc).

> Also because 
> insts are something the average Mercury programmer delves into somewhat 
> rarely (IMHO) and the construct for state variable types and modes was 
> meant to make life easier, and to simplify the typing the programmer 
> already did, not add to the required learning curve by requiring a 
> deeper understanding of insts.

This argument doesn't wash with me, for atleast two reasons:

	- Existing modes are already parameterised by insts in Mercury.

	- Insts are really not that hard to reason about, once the roles
	  of the three components are understood.  It is mainly the fact
	  that these three components are lumped together under the concept
	  of inst that makes them complicated for new (and old) users.
	  With better support for expressing subtypes and uniqueness, insts
	  would be used a lot more frequently in my estimation.

Cheers,
Mark.

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