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

[diffense]

Ralph Becket <rafe at cs.mu.OZ.AU> wrote:

diffense, Tuesday, 22 June 2004:

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

But wouldn't overuse of mutvars and stores amount to programming imperatively
(not declaratively) using mercury syntax instead of C syntax? That is what I
would rather avoid doing.

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

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

Superficially, mercury seems like a cross between ML and prolog but there are
many more concepts to grasp before one can really use it effectively.

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

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

Yes, it was a mistype. It should have been.

member([H|T], H).

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

I have a little experience with prolog and I remember the order of clauses
being quite important so I (wrongly) assumed the same of mercury. IIRC the
interpreter would also try to prove subgoals in left to right order. Now after
learning I can't think about mercury this way, I'm not quite sure where to
start.

Is there any reading material you'd recommend. (I've already gone over most of
the information on the site).



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





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