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

[Ben Schmidt]

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

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

I disagree; they can be easily parameterised when you realise that the 
true unique equivalent of in!out is not di!uo, but ui!uo:

in!out: ground >> ground, free >> ground
ui!uo:  unique >> unique, free >> unique

The di==unique>>dead mode is, I think, a fundamentally different 
concept. It's output equivalent would, I think, be a kind of 
compile-time garbage collection concept embedded in the mode system (and 
probably implemented as a destructive update as an optimisation). It 
would be something like recovered-output == ro == dead>>unique, but with 
a specific idea of which 'dead' variable/cell is being recovered (so 
perhaps only allowed in a state-variable context where it is clear which 
destroyed input is being referred to). It would allow a heap of 
optimisations, as the compiler would know when destructive updates were 
occurring, and would be able to remove various unifications, use less 
memory and do less copying, and so on. But it isn't a unique equivalent 
of in!out, and cannot so be made to correspond to it in some 
parameterisation. There is no non-unique equivalent to this, as

ground >> dead, dead >> ground

is no good, as killing a non-unique term is not really possible, unless 
you can be sure you are also killing all terms that reference it, which 
would seriously complicate things, and

ground >> free, free >> ground

is really not going to happen, as freeing variables is not something 
that logic is designed to do (except arguably on backtracking, but that 
doesn't happen as part of forward execution)!

The bottom line is that I think the state variable syntax is useful in 
distinct, non-equivalent situations which can't be parameterised as a 
transformation of insts. You could allow parameterisation, but it 
wouldn't give the expressiveness desired here. The mode combinations 
in!out, ui!uo, and di!uo (and/or arguably di!ro given my discussion 
above) all need to be easily expressible, which can only be done neatly, 
I think, by including the input and output modes explicitly.

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

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. A 
redesign of the mode system will probably require more than a change in 
this particular piece of syntax, too, so, IMHO, it'd be worth including 
the change.

 > One technical problem with this is that it could easily leading to an
 > exponential explosion in the amount of code generated.

O yeah. I was only thinking of expressiveness, not implementation. In a 
less-efficient system which interpreted or did dynamic compilation, it 
would work, but it can't really work in Mercury. The eternal concept of 
the tradeoff.

Grins,

Ben.



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