[m-dev.] Feature proposal: generic inline iterations

[Sebastian Brand]

Hi Mark,


|  It would be nice if the new feature worked well with state variable syntax.
|  For example, using the above form, it could be possible to write
|  
|  	fromto(First1, !Local1, Last1)
|  

Good point.  This would be quite useful in case of nested
iterations (the parent loop has local vars, the child loop
as well).  On the other hand, there is a value in sticking
to established state of affairs.  So I'd have a slight
preference for the given ordering.



|  > 	do_XX(In1, ..., InN, Last1, ..., LastN) :-
|  > 		In1 = Last1,
|  > 		...,
|  > 		InN = LastN.
|  > 
|  > 	do_XX(In1, ..., InN, Last1, ..., LastN) :-
|  > 		body(In1 ..., InN, Out1, ..., OutN),
|  > 		do_XX(Out1, ..., OutN, Last1, ..., LastN).
|  > 
|  > 
|  > The determinism of do_XX can ideally be inferred from the body;
|  > typically it is semidet or det.
|  
|  I think it would be hard for the compiler to prove this in general.  That
|  is, it would be hard for the compiler to prove that the above two clauses
|  are mutually exclusive, so it could only infer that the goal is multi or
|  nondet.  Maybe the meaning of it should instead be:
|  
|  	do_XX(In1, ..., InN, Last1, ..., LastN) :-
|  		(
|  			In1 = Last1,
|  			In2 = Last2
|  		->
|  			In3 = Last3,
|  			...,
|  			InN = LastN
|  		;
|  			body(In1, ..., InN, Out1, ..., OutN),
|  			do_XX(Out1, ..., OutN, Last1, LastN)
|  		).
|  
|  where I've assumed that (First1, Last1) and (First2, Last2) have the
|  (in, in) modes and the others are (in, out) or (out, in).

I think this is exactly what should happen.  Thanks for
pointing this out.  The original uses a cut after the
InN = LastN...  The purpose of the whole business is not so
much to push static analysis to the limit but to
simplify common programs and programming.  Probably all
instances of such loops that I encountered or produced were
intended to be det or semidet and had an argument i where
both First_i and Last_i are 'in'.


|  It would be desirable to be able to specify the modes of the fromto/4
|  arguments and to specify the determinism of the goal, much as we do for
|  lambda expressions.  In fact, it may be necessary to do this if mode/detism
|  inference proves too hard to implement.
|  
|  For example, the following specifies the modes:
|  
|  	(
|  		fromto(First1::in, In1::in, Out1::in, Last1::in),
|  		fromto(First2::in, In2::in, Out2::out, Last2::out)
|  	do
|  		...
|  	)

I'd hope very much that this could be avoided, and that
looking at the context would suffice.  Perhaps it can be
optional, to be used when the compiler analysis fails.



|  > Parameter passing is done by a fromto(P, P, P, P).  Etc.
|  
|  It would be nice to be able to use non-local vars in the body.  These would
|  be processed as extra arguments to the do_XX predicate (similarly to how we
|  handle non-locals in lambda expressions).

The more readible shortcuts, eg. foreach(X, List),
for(I,A,B), param(P) = fromto(P, P, P, P), can be treated a
bit more cleverly than by a direct reduction to their
fromto form.  For param(P), one doesn't need a separate Out
argument; same goes for foreach, where Out = [].



|  There's definitely a few details left to work out, but I
|  think it is worth pursuing this proposal.


I should have pointed this out earlier:  the paper

	J. Schimpf. Logical Loops. ICLP 2002.
	http://eclipse.crosscoreop.com/eclipse/reports/loops.pdf  /.ps

discusses the issue in detail.  There's also a useful PPT
presentation.  Googling the obvious keywords finds you
Eclipse code by J.S. that does the transformations.


Cheers,
Sebastian
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------