[m-dev.] semantics with any insts

Mark Brown mark at cs.mu.OZ.AU
Mon Apr 3 16:31:26 AEST 2006

On 03-Apr-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> On Mon, Apr 03, 2006 at 01:31:13PM +1000, Mark Brown wrote:
> > Can you give an example of where the declarative reading would really
> > benefit?
> Sure.  The declarative reading of determinism helps me make sure I
> handle all cases of a union type, and that IO is safe.  Both of these
> currently go out the window with any insts.
> If you mean the declarative reading of determinism for modes with some
> final any insts, no I can't.

That's the case I'm interested in.

> It's effectively always nondet, so
> there's no declarative information to make use of.
> > In fact, can you define what the declarative reading actually is?
> Determinism specifies upper and lower bounds on the cardinality of the
> success set.

Nope, that's not it.  The success set of list.append, for example, is
the same regardless of the mode, but the determinism isn't.  Also, the
success set won't let you distinguish between `failure' and `erroneous'.

> That's how I've always thought of it, and I believe
> that's how it was initially described to me.  Given that that is an
> inherent property of the code, and that choicepoints and backtracking
> are not the only possible way for Mercury to implement nondeterminism,
> that's the only reading that will be stable over time.
> > The
> > existing definition in the reference manual talks about "inputs" and
> > "outputs", but with the xor example both arguments are partly input and
> > partly output.
> "Output" just means the universal set of possibilities; "input" means
> a singleton set of possibilities.  "Any" means any set of
> possibilities, including the empty set.

Right, so "input" only means mode `in', not mode `ia'.

In that case, I agree that the (declarative reading of the) determinism of
constraints would always be nondet.  And useless.

(For the record, my '+' example read "input" as including `ia', but even
then I don't think it provided any strong motivation.)


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

More information about the developers mailing list