[m-dev.] semantics with any insts

[Ralph Becket]

Peter Schachte, Monday,  3 April 2006:
> 
> I thought Mercury didn't support partial instantiation?

That's true at the moment (I'd argue for keeping it true.)

> You're right
> about unused modes (I assume this is free>>free), but aren't they
> pretty much unused?  I can't see when you'd use one.

There are times when you need the type info of a variable, but not the
variable itself.  Some of the RTTI routines use this trick to obtain a
type info for a variable that isn't actually realised anywhere in the
program.

> Anyway, the crux of my objection to turning determinism into (or
> accepting that it has become) an operational rather than a declarative
> thing, is that it then forces users, solver writers, and the Mercury
> implementation to commit to implementation decisions that should be
> changable.  Maybe today a solver writer implements a primitive
> constraint by backtracking over possible solutions because it's easy,
> and tomorrow does something clever to avoid backtracking.

That sort of implementation detail *should* remain hidden, regardless of
whether detisms are given a declarative or operational reading.  Maybe
I've misunderstood; can you give an example of what you have in mind?

(The only place where I can think this might happen is when the
programmer has used the backtracking approach, but erroneously not put
that code inside a promise_equivalent_solutions scope, and compounded
the error by declaring the predicate to be multi or nondet.)

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