[mercury-users] Partially instantiated modes

[David Overton]

On Thu, 11 Nov, 1999 at 03:23:03PM EST, Thomas Conway wrote:
> Hi
> 
> A couple of months ago there was a brief threadlet about whether partially
> instantiated modes were really useful, and/or what they were useful for.
> The other day I came across a situation where they would be really useful:
> 
> If you have a mercury program preprocessor that has to create a wrapper
> procedure around a given goal, and has to introduce some variables. I
> ended up with some code that looked like:
> 
> ...
> 	varset__new_named_var(VS7, "XX1", XX1, VS8),
> 	varset__new_named_var(VS8, "XX2", XX2, VS9),
> 	varset__new_named_var(VS9, "XX3", XX3, VS10),
> 	varset__new_named_var(VS10, "XX4", XX4, VS11),
> 	varset__new_named_var(VS11, "XX5", XX5, VS12),
> 
> 	CLAUSE = functor(atom(":-"), [HEAD, BODY], Ctxt),
> 	HEAD = functor(atom("thingumy"), [variable(XX1), variable(XX2), ...],
> 		Ctxt),
> 	BODY = ...
> 		mentioning the created variables and some other bits and
> 		pieces that were the read in terms WRT the varset VSnn
> 	
> It's horrible to maintain because adding more variables is difficult
> because of all those VSnns that have to be changed, and higher order
> doesn't really help:

This looks like an argument for re-arranging the standard library to
make predicates easier to use with DCG syntax and/or higher order.
If varset__new_named_var was changed so that the varset was threaded
through the last two arguments you could use the DCG syntax to get
around the variable numbering problem.  Incidentally, the predicate
would then also have its arguments in the correct order for
map__foldl, removing the need to write out an explicit lambda
expression for the code below.

> 	map_foldl((pred(Name::in, Var::out, VSx::in, VSy::out) is det :-
> 		varset__new_named_var(VSx, Name, Var, VSy)
> 	), ["XX1", "XX2", ...],
> 		[XX1, XX2, ...], VS7, VS8)
> 
> The problem is that unification of the output with the list of variables 
> is semidet, so putting the problem _could_ be fixed with an if-then-else,
> but that's kind of awful too.
> 
> However, if I could write:
> 
> :- mode fill_in_snd = (listskel(pair(ground, free)) -> ground).
> 
> :- pred makevars(list(pair(string, var)), varset, varset).
> :- mode makevars(fill_in_snd, in, out) is det.
> 
> makevars([], VS, VS).
> makevars([Name - Var|Rest], VS0, VS) :-
> 	varset__new_named_var(VS0, Name, Var, VS1),
> 	makevars(Rest, VS1, VS).
> 
> Then I can use it in the following way:
> 	makevars(["XX1" - XX1, "XX2" - XX2, ...], VS7, VS8)
> 
> This is good because it is easily extensible, where the original
> was not.
> 
> Here the win is not in runtime efficiency, but programmer efficiency.
> 
> Comments?

This sort of code should be easily handled by our experimental
alias-tracking compiler.  I've just started up a compiler build to
test it out.


David
-- 
David Overton       Department of Computer Science & Software Engineering
PhD Student         The University of Melbourne, Australia
+61 3 9344 9159     http://www.cs.mu.oz.au/~dmo
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------