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

[Ralph Becket]

diffense, Tuesday, 22 June 2004:
> 
> 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.

Absolutely.  But the option is there if you need it.

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

That's a fair description although we don't support full Prolog style
unification(*) and unlike either of those languages Mercury is purely
declarative.

[(*) I'm working on support for this sort of thing right now,
however.]

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

No, in general you can't rely on order of execution in a Mercury
program.  Anyway, that's imperative thinking - focus on the "what" and
leave the "how" to the compiler.

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

I'll e-mail you the first 100 pages or so of the Mercury book that I
really, *really* must get around to finishing this year...

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