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

[Ralph Becket]

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

Now we can use foldl2 with io__write_string, say, as its first
argument.  

I ought to make the point here that I am suggesting alternative
syntax to tackle what I see as a serious flaw in the current
EDCG proposal.  I haven't worked out all the details of how the
syntax should be changed, so please feel free to make any
obvious assumptions about how it might turn out in practice.

[Back to the foldl2 example]
> 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?

If we wanted a specialised htype and mode for the io library, say, 
then we'd write

:- htype io : io__state.
:- hmode io : (di, uo).

:- pred io__write_string(string, $~io).
:- mode io__write_string(in, $~io) is det.

> Similarly, if the code for that predicate happened to contain
> 
> 	$x = $y
> 
> then that expansion would be wrong too.

I don't understand this.  If this makes the higher order argument
semidet then of course the modes given would be wrong - so you just
add the mode for folding with semidet predicates.

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

> > Actually, we should constrain the types of some var args
> > ...  var(x:TX, y:TY).
> 
> OK, that would work.  But then you have to annotate the
> types at every point, whereas the advantage of `:- htype'
> declarations is that you only need to specify the type
> in one spot.

You only have to annotate at pred/mode declarations, not at 
the call sites.  The call sites only have to be told which
state threads are being passed.

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