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

[Ben Schmidt]

That syntax solution seems pretty good, Richard.

I'd go for the version that uses ! for variables and types, but 
parentheses only for modes, i.e. dot product type expansion of :: but 
not scalar*vector type expansion, and ! implying splitting one argument 
into two. I don't like it without any !s, as I think one type or 
variable shouldn't represent two without a !.

Certainly best to save !(...) type notation for such time when 
modes/insts have been more thoroughly thought out. And although I like 
the conciseness of in!out, and don't think that clouds the meaning of ! 
like !(in,out) does, concede that the parentheses do seem to have the 
upper hand in terms of readability. So we'd have

:- pred p(T, !acc_type, !io.state).
:- mode p(M, (in, out), (di, uo)) is Det.
p(V, !AccVar, !IO) :- Goal.

:- pred pp(T::M, !acc_type::(in, out), !io.state::(di, uo)) is Det.

lambda(V::M, !AccVar::(in, out), !IO::(di, uo)) :- LambdaGoal

It is really obvious what it means, thoroughly consistent and not making 
premature use of !.

Agree with Julien that different syntaxes for declarations and lambda 
expressions are not on.

Ben.



Richard Fothergill wrote:
> On 1/15/07, Mark Brown <mark at csse.unimelb.edu.au> wrote:
>> 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).
>>
> 
> I agree. I'm glad it came up.
> 
> On 1/15/07, Ben Schmidt <b.schmidt at ugrad.unimelb.edu.au> wrote:
>>
>> Probably much more could be discussed about the mode of state variables,
>> but I think what was being originally suggested and what people seemed
>> to like in principle, was syntactic sugar--just a convenience, and a
>> syntax transformation, not a redesign of the mode/inst system. It may
>> not be fully parameterisable or 100% consistent with other notation, but
>> it's certainly convenient and improves clarity and readability.
> 
> In that case, consider making '::' distribute over ',' so that
> "mysvtype::(in, out)" is equivalent to "mysvtype::in, mysvtype::out".
> (Note: I don't know what sort of parsing and/or error message
> difficulties this will create.)
> 
> A state variable syntax using '!' could be introduced later, but for
> consistency, I think the '!' should be restricted to a !x -> f(x),
> g(x) syntactic conversion (e.g. !IO -> !.IO, !:IO). Specifically I
> think it should always imply breaking a single parameter into two.
> 
> -Richard
> 
> 
> 
> P.S.
> 
> On 1/12/07, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>> The other place this sort of syntatic sugar would be really useful
>> is in the heads of lambda expressions:
>>
>> e.g.
>>
>>         X = (pred(!IO::!(di, uo)) is det :-
>>                 ...
>>         )
>>
>> as opposed to:
>>
>>         X = (pred(!.IO::di, !:IO::uo) is det :-
>>                 ..
>>         )
>>
> 
> My suggestion above wouldn't accommodate this. However, I've been
> thinking along the lines of vectors, scalars and dot products.
> 
> If u, v, w, x, y and z are in R (the reals), then we have:
> 
> u(x, y, z) equivalent to (ux, uy, uz)
> (u, v, w).(x, y, z) equivalent to ux + vy + wz
> 
> We could similarly have:
> 
> mysvtype::(in, out) equivalent to "mysvtype::in, mysvtype::out"
> (mysvtype, mysvtype)::(in, out) equivalent to "mysvtype::in, mysvtype::out"
> 
> The latter of which is essentially useless, except generalised it
> means that lambda expressions can use:
> 
> !MySV::(in, out)
> 
> Also, if a type-based (as opposed to a variable-based) '!' sugar were
> simply defined as "!type -> type, type" then the former transformation
> above would become redundant, as we could use:
> 
> !mysvtype::(in, out) equivalent to "mysvtype::in, mysvtype::out"
> 
> Lastly, if some form of mode-based '!' sugar were to eventuate from
> the sort of discussion of modes Mark suggested above, we would
> probably end up with something like:
> 
> !mysvtype::!SOMETHING
> --------------------------------------------------------------------------
> 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
> --------------------------------------------------------------------------
> 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------