[m-dev.] Unique Modes and Transaction Logic

[Mark Brown]

On Sun, Jul 20, 2014 at 04:13:44PM -0400, Marcus Troyka wrote:
> On 07/20/2014 04:00 AM, Mark Brown wrote:
> > I'm still just guessing what problem you are solving, though. The
> > first of the papers you referenced has two practical examples, one on
> > financial transactions and one on robot actions. The first example can
> > be expressed in Mercury using unique modes (section 5.1 of the
> > reference manual), and the second using "mostly unique" modes (section
> > 5.2) and committed choice non-determinism (sections 6.4 and 6.5). So
> > Mercury's modes appear to be sufficient to address the problems raised
> > by this paper, at least.
> Well, mostly I was just considering mercury as a whole, as it applies to
> AI, databases, and general programming.

It's hard to know what you are asking for. I think the reason Mercury
uses the predicate calculus rather than some alternative like
transaction logic is because it is simpler, in the sense of requiring
less information to understand, while still being able to explain what
values are computed. This simplicity benefits people who have to read
the code.

Regarding databases, transaction logic can give a meaning to the sort
of deductive database that allows updates to occur from deep within
queries, rather than just at the top level. Not all deductive database
implementations consider it necessary to allow this, though, so I'd be
interested in knowing what the motivating examples are. It seems to me
it would make useful optimizations harder to implement.

Regarding AI, if there are AI practitioners who come to Mercury hoping
to find something with the full expressiveness of Prolog but much more
efficiency, I think they will be disappointed.

> > Yes, perfect static determinism checking is not possible in general;
> > see the discussion in section 6.3. I dare say it is not possible to
> > prove much about `assert'.
> In logic languages, no. In functional languages it's pretty easy (and
> all functions have to be det anyway).

I don't understand this point. I was advising you not to insist on
completeness because it would be impossible. The discussion I referred
to shows that completeness isn't necessary.

> > For my money, the biggest advantage of logic programming over
> > functional programming is that you can have multiple output arguments.
> > In functional syntax, if a procedure has more than one output you are
> > forced to either cram everything into the one return value, or else
> > make use of side effects.
> I should mention that C carries that same limitation, but in practise it
> doesn't usually matter. The way side effects are used in OO is a bit
> different, but in functional programming a major advantage is that since
> functions only produce one output value (and are always det) they can
> use evaluate-in-place semantics, which are easy to read and understand.

Predicates can also be unfolded in-place, which is a consequence of
being defined by an equivalence relation. I agree with you that it is
a major advantage of pure code over code that uses side effects,
though.

>  Is there actually a real situation where "ui" can occur?

library/array.m

Cheers,
Mark.