[m-dev.] Re: Visual vs total arity clash example [fwd]

[Fergus Henderson]

On 28-Jan-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> Peter Schachte [mailto:schachte at cs.mu.OZ.AU] wrote:
> > 
> > The main problems with procedural programming like
> > this are that data structures intended as inputs may be modified
> > without your knowing it, and since side effects can't be predicted,
> > compilers can't optimize code very well.  With EDCGs, you only need
> > look at the predicate declaration to know what a predicate call might
> > change.  And since the compiler has this information as well, it's
> > free to optimize.
> 
> Well, (1) there are several decent languages out there that do allow you
> to specify the modes of various arguments to procedures (e.g. Modula-3
> has READONLY and VAR parameter modes)

The problem arises in procedural languages due to the possibility
of aliasing.  If aliasing of mutable variables or parameters is allowed,
then a change to any parameter might end up modifying any other parameter
(or part thereof). 

The EDCG proposal does not suffer from the same kinds of problems that
Module-3 suffers from in this respect, because it does not allow that
kind of aliasing.

> in this case ... I think EDCGs are more obscure than the equivalent
> C or whatever:
> 
> void prepend(list xs, list *acc) {
> 	if(!empty(xs)) {
> 		prepend(tail(xs), acc);
> 		*acc = cons(head(xs), acc);
> 	}
> }
> 
> This is slightly clearer because it's obvious in the recursive call
> that acc is part of the process.  In the mercury version,
> 
> prepend(Xs) -->>
> 	(	Xs = []
> 	;	Xs = [H | T], prepend(T), $=acc = [H | $acc]
> 	).
> 
> it is far from obvious that the call to prepend has anything to do
> with acc; the problem is worse if we're calling some different
> predicate that changes acc.  These variables aren't locals, they're
> almost globals!  Ack!
> 
> This is one of the reasons why I'd like to be obliged to
> specify what variables are being passed to a call *at the call site*,
> e.g.
> 
> prepend(Xs) -->>
> 	(	Xs = []
> 	;	Xs = [H | T], prepend(T) + changes(acc), $=acc = [H | $acc]
> 	).

I think there are some cases where you want that.
I think there are also other cases where specifying that
at every call site would be cumbersome.

> > > {REQUEST: can we change `changed' to `changes'?  It's a
> > > declaration, not a statement.)
> > 
> > Good point.  How about `uses' `changes' and `produces'?  Or even `in'
> > `out' and `inout'?
> 
> in, out & inout (or, better, `var'?) would be much preferable!

When EDCGs were first proposed, I suggested the same thing.

The concept is indeed analagous to in/out/inout,
but it applies at the level of "mutables"
(i.e. the things named by EDCG hidden argument names --
the things that we were calling "thingees" in the meeting),
and refers to the binding of mutables to variables,
rather than being at the level of (logic) variables, and
referring to the binding of variables to values.
The rationale for not using `in' and `out' was that it
would be too confusing if there was a mutable whose
"EDCG mode" was `in', but whose mode was `out'.

But the current names are a bit too verbose, IMHO;
I'd prefer something shorter.

> Hmm, let's see what foldl2 looks like with vars and call-site annotation
> in Ralph's New Syntax:
> 
> :- pred foldl2(pred(T) + var(x, y), list(T)) + var(x, y).
> 
> foldl2(P, Xs) + var(x, y) -->>
> 	(
> 		Xs = []
> 	;
> 		Xs = [H | T],
> 		P(H) + var(x, y),
> 		fold2(P, T) + var(x, y)
> 	).
> 
> Now that really isn't too painful either on the fingers or on the eye,
> while at the same time making it obvious what is going on.

If we were going to go with something like this,
I'd prefer preceding the mutable names (x, y) with some
special symbol such as `$'.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------