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

[Fergus Henderson]

On 31-Jan-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> > From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> > 
> > > > :- 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)
> > > > 	).
> > > 
> > > Thinking more about this, I think we might be able to do away
> > > with the `htype' etc. declarations.  Consider:
> > > 
> > > :- pred foldl2(pred(T) + var(x, y), list(T)) + var(x, y).
> > > :- mode foldl2(pred(in) + var((in,out),(in,out)) is det, in) +
> > > 	var((in,out),(in,out)) is det.
> > > 
> > > would have the obvious expansion:
> > > 
> > > :- pred foldl2(pred(T, TX, TX, TY, TY), list(T), TX, TX, TY, TY).
> > > :- mode foldl2(pred(in, in, out, in, out) is det,
> > > 	in, out, in, out)	is det.
> > 
> > But if mutable x has type `io__state', then that expansion would
> > be wrong.  It's OK in this case, because foldl2 can be polymorphic,
> > but there are many predicates, e.g. io__write_string, which can't
> > be polymorphic; how would the expansion work in that case?
> 
> There's nothing to stop one adding more mode declarations, nor abstracting
> over the var() declarations.  In the (evolving) syntax, one might write
> 
> 	% $~x denotes an in/out arg pair for state thread x.
> 	% $x denotes the current value.
> 	% $=x denotes the updated value.
> 
> :- htype x(T) : T.
> :- hmode x : (in, out).		% These get expanded in-line for
> :- hmode ux : (di, uo).		% htype args.
> 
> :- pred foldl(pred(T1, $~x(T2), list(T1), $~x(T2)).
> :- mode foldl(pred(in, $~x) is det, in, $~x) is det.
> :- mode foldl(pred(in, $~ux) is det, in, $~ux) is det.

That syntax looks OK; it doesn't have the flaw that I was
referring to above.

> > Similarly, if the code for that predicate happened to contain
> > 
> > 	$x = $y
> > 
> > then that expansion would be wrong too.
> 
> I don't understand this.

My point here was that whether `var(x, y)'
should expand to `T1, T1, T2, T2', as you suggested,
or `T1, T1, T1, T1' depends on the code in the body
of the procedure, i.e. neither choice will be right
for all cases.  Hence I think that for polymorphically
typed arguments, it is better to have a syntax which makes the type
parameters explicit, e.g. `var(x(T), y(T))' or 
`var(x : T, y : T)' or `$~x(T), $~y(T)',
rather than using a syntax like `var(x, y)'.

> > So I don't think it works in enough cases to be worthwhile,
> > even as a special case of the notation that you discuss below:
> 
> Nah, I don't believe it!

Perhaps the argument above is a bit clearer.

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