[m-dev.] Proposal: sequence quantification

[schachte at cs.mu.OZ.AU]

On  3 Jan, Ralph Becket wrote:

> I'd really like to see some details of the transformation.

That's up in the air a bit now.  I have a Prolog implementation of most
of this, but in many ways it's easier in Prolog than Mercury.  On the
other hand, I've put some work into optimization for Prolog that's
completely unnecessary for Mercury.  Let's just say that we're shooting
for generating the sort of first-order code you would write if you were
thinking about efficiency.

>> 	for E in Sequence as Curr initially no finally yes(LastElt) ::
>> 		next Curr = yes(E)
> 
> Presumably this could also be written as
> 
> 	for E in Sequence as Curr initially E finally LastElt ::
> 		next Curr = E

No, E is scoped to the quantified goal, and can't be used in other
quantifiers in the same quantification.

> or would it have to be written as
> 
> 	Sequence = [Init | _],
> 	for E in Sequence as Curr initially Init finally LastElt ::
> 		next Curr = E

This would work fine, though I'd be more inclined to avoid visiting the
first argument twice:

	Sequence = [First | Rest],
	for E in Rest as Curr initially First finally LastElt ::
		next Curr = E

> `as' requires both L and R sequences to be the same length - does it
> fail quietly if they are not (i.e. is semidet code generated) or is
> an exception thrown?

It quietly fails.

> If the former, I think there is scope for a
> version with the latter behaviour as that will be quite common
> (call it `det_for' or something, or maybe make `for' the det case).

Hmmmmm.  Yes, I can see that being useful.  OTOH, one big point of this
whole thing is to be useful in different modes, including generating
sequences.  That means that:

	det_for A in L1 as B in L2 :: Goal, L2 = [a, b, c]

might quietly fail while

	L2 = [a, b, c], det_for A in L1 as B in L2 :: Goal

would raise an exception.  That doesn't seem very nice to me.  What's
the language's position on commutativity of conjunction with respect to
the finite failure set?

>> The `when' operator employs a
>> bit of syntactic sugar:  `E in List when E > 0' is equivalent to `E in
>> filter(List, (pred(X::in) is semidet :- X > 0))', but easier to write.
>> 
>> Similar are `while' and `until', which take the front of a sequence up
>> to but not including the first element for which a condition fails
>> (succeeds).
...
>> Similarly, the `once' operator drops the front of the sequence up to
>> the point that a predicate holds

> Can these be composed, as in
> 
> 	for E in List once E >=0 while E < 10 ...

Yup.

> On the matter of the transformation only applying to lists in the
> first instance, I presume that `X initially A finally Z' will be
> an accumulator

That's the plan, though as I said, it's still a bit up in the air.  The
Prolog version generates an accumulator pair, though it works on an
older, uglier syntax instead of `initially ... finally ...'.

-- 
Peter Schachte                     The use of COBOL cripples the mind; its
mailto:schachte at cs.mu.OZ.AU        teaching should, therefore, be regarded
http://www.cs.mu.oz.au/~schachte/  as a criminal offense.
PGP: finger schachte at 128.250.37.3      -- E. W. Dijkstra 

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