[m-dev.] Inductive goals

[Mark Brown]

On Thu, Jan 23, 2014 at 1:20 PM, Peter Schachte <pschachte at gmail.com> wrote:
> The keyword 'maps' seems a bit quirky.  Why not 'in'?  It reads much
> more naturally.

Given the semantics, 'maps' and 'folds' are both instances of 'in'. I
needed to distinguish the two cases so the syntax is unambiguous, and
I thought the analogy with the map and fold predicates was reasonable.

The inspiration for this dual approach, BTW, is that Joachim encoded
his map-like sequences into fold-like ones, whereas you encoded
fold-like sequences into map-like ones (using thread/2). It reminded
me of how functions can be encoded as predicates and vice-versa,
particularly since functions are a natural fit for list.map whereas
list.fold works more naturally with predicates. Mercury has both
functions and predicates, so it seemed in the spirit of things to
include both maps and folds on equal footing.

> Also, using square brackets for what must be pairs of
> values in the folding syntax runs counter to the arbitrary length of
> lists.  How about using braces (tuples) instead?
(snip)
> Your example uses "[I, I + 1] folds [0, N]", but wouldn't 'I in 0..N' do
> the same thing, and read much better?

They look like fenceposts!  :-D

Picture a fence made up of N segments, with fenceposts between each
segment, as well as at the start and end. The fenceposts are numbered
from 0 to N. If you were iterating over the segments of the fence,
each segment would look like [I, I + 1]. The fence as a whole looks
like [0, N].

Compare with <http://www.catb.org/jargon/html/F/fencepost-error.html>.

The expression 'I in 0..N' might be more susceptible to fencepost
errors. (Indeed, perhaps you meant to write 'I in 0..(N-1)'?)

>
> I really like the 'mismatch' goal.  I assume the default mismatch goal
> is 'fail', but you could make it 'true' if you wanted, or an error, as
> in your example, or unifications to give final values for folds.  Nice.

It seems necessary to give the user a choice between failing and
throwing an exception, since the code that converts one fixed choice
to the other is klunky in either case.

Allowing success doesn't work out nicely, though. If an goal succeeds
in a mode where there are two input sequences that don't correspond,
then, for consistency, it must also produce that solution when there
is only one input sequence. There's an infinite number of these
solutions: one for each output sequence whose length doesn't
correspond.

> Having "do true" on the end may be reasonably common; you could make the
> 'do' optional, and true the default goal.

That would lead to a "dangling do" problem. You don't want to go there.

Cheers,
Mark.