[mercury-users] New to mercury: structure reuse and efficiency

[Ralph Becket]

diffense, Tuesday, 22 June 2004:
> I agree, and I am relucatant to program imperatively in mercury. That gives up
> many of the advantages I'm trying to gain. 

I think you'd be (pleasantly) surprised.

Unless you're working right next to the metal, in which case you might
as well use C for the performance critical sections of your code, I
honestly can't see you noticing any performance problem.  Indeed, I've
often found the greater simplicity of declarative programming makes it
easier to make algorithmic improvements.

> It's great to hear that work is still continuing. I was wondering how active
> the mercury development community is now. 

Mercury is alive and well and under active development.  The existing
system is lacking in only a few details before we release v1, about the
only serious problem being support for uniqueness.

> As I began looking for a functional/logic language to use it just
> turned out that mercury (which I had overlooked initially) fit the
> criteria of speed, purity, minimalism and expressiveness that I had
> set. Unfortunately there is a much larger volume of information on how
> to program in ML, Haskell, Clean or Scheme making mercury a bit more
> of a challenge to learn. If I ever manage to understand it enough I'll
> have to help change that.

Sure.  But these things are much of a muchness: once you can program in
one, the others are all rather similar.  Mercury is only slightly
different in that it also supports logic programming.

> A little more information on mercury's operational semantics would
> have been great. For instance, in the example below, is the not(X=Y)
> necessary? IMO, it is very important (from a programmers perspective)
> to understand how the execution environment attempts to prove
> predicates.

Well, to a first order approximation, execution order is not something
you specify in a declarative programming langauge.  That is left up to
the compiler.  The *declarative* semantics of Mercury programs are
pretty much that of first order predicate calculus.

Operationally, you can constrain the semantics still further with flags
like `--strict-sequential', although it's not clear why you'd want to do
that in general.

> member([H|T], H).
> 
> member([H|T], X) :- not(X=Y), member(T, X).

This is one of those places where Mercury differs from languages like ML
and Haskell.  In Mercury, a set of clauses is *not* syntactic sugar
for a chain of if-then-elses, but rather for a disjunction in which
there is no special order on the disjuncts.

Similarly, since A, B (where `,' is read as `and') is logically
equivalent to B, A, the order of conjuncts is not generally significant
either.

The compiler has great freedom to rearrange your code!

The upshot of this is that the `not(X = Y)' goal in there (I presume the
`Y' is a typo?) is superfluous and probably doesn't do what I think
you were trying to achieve.

-- Ralph
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------