[m-rev.] for review: state vars syntax sugar

Ondrej Bojar obo at cuni.cz
Tue Jan 30 15:19:00 AEDT 2007


Peter Schachte wrote:
> My updated proposal:
> 
> 	pred declarations:	!type specifies type for a state variable
> 	mode declarations:	!inst specifies instantiation of a state var
> 	predmode declarns:	!(type::inst) specifies type and inst for
> 				state variable

I like that. I like the conceptual shift to state variables being pure 
locally mutable variables. I like your argument against inst (and type) 
changes of state vars.
[Syntactically, I prefer !type::inst to !(type::inst), as if the 
priorities of :: and ! were different in this context.]

However I understand that for educational purposes, the two pipes of 
stateless variables are more appealing. The !type::(in, out) syntax 
stresses that aspect: remember, there was a value that went in and there 
is a value that gets out, and you can give a name to each of these and 
you can think about (type/)inst changes.

So the main controversy is who has the right to canibalize 'bang', i.e. 
what everything is included in the concept of a 'state variable'. Is a 
state variable just a simple common notation for a thread of chained 
variables, or do these variables have to satisfy certain properties, 
namely the same type and compatible instantiatednesses.

I prefer Peter's account, but I definitely do not mind allowing the less 
restrictive approach as well. After all, the proposal does not aim at 
forbidding the current syntax, e.g. lambdas:
   pred(!.Aku::in, !:Aku::uo).

> If you find it annoying, as I do, that pred and mode declarations specify two
> types and modes for a predicate when the call looks to only have one, then I
> think my proposal works better.  If, OTOH, you're just looking for a way to
> save yourself from having to repeat type specifications over and over in pred
> and predmode declarations (that's the only benefit I see from the current
> proposal), then the following 2 changes, taken together, are more widely
> applicable and seem simpler than the current proposal:
> 
> 	In a predmode declaration, allow Type::(Inst1,... Instn) as an 		abbreviation
> for Type::Inst1, ... Type::Instn.   Eg, :- pred append(list(T)::(in, in, out)).
> 
> 	In a pred declaration, allow N * Type, where N is an integer, as an
> abbreviation for N repetitions of Type.  Eg:  :- pred append(3 * list(T)).

I agree, I just do not wish people to use N*Type, because in most cases 
(preds up to arity of ~7) complicates reading. But I like the first 
part: Type::(Inst1, Inst2, ...) I even like allowing both the 
!type::inst and type::(inmode, outmode), leaving the choice to style 
preference of the programmer.

O.

-- 
Ondrej Bojar (mailto:obo at cuni.cz)
http://www.cuni.cz/~obo
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list