Re: How to fight semideterminism in Mercury?
From: Dmitri Soshnikov (dsoshnikov_at_gmail.com)
Date: 10/19/04
- Next message: Ralph Becket: "Re: How to fight semideterminism in Mercury?"
- Previous message: Dmitri Soshnikov: "Re: How to fight semideterminism in Mercury?"
- In reply to: Bart Demoen: "Re: How to fight semideterminism in Mercury?"
- Next in thread: Ralph Becket: "Re: How to fight semideterminism in Mercury?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 18 Oct 2004 15:42:18 -0700
Bart,
> > SOLUTION 2
> >
> > However, a simpler solution is to simply specify that your original
> > add function always returns a non-empty AVL-tree:
> [...]
> >
> > SOLUTION 3
> >
> > This is a bit of a hack, but if you stick to the if-then-else style
>
> Ralph,
>
> What you wrote seems to suggest that your solution 2 cannot be combined
> with the if-then-else style without resorting to the hack. Is that true ?
I believe it is not necessarily true, because, once we declare that
non-empty tree is returned, we can keep the original if-then-else
style of definition for add (I have actually tested this). The only
problem occurs with one unification inside combine, which I have
mentioned in my previous posting in repsonse to Ralph's, where
resorting to the hack mentioned in solution 3 seems like the easiest
solution to the problem. However, it can also be partly justified from
declarative point of view, so it is not really so much of a hack...
> You also wrote:
>
> > Just as a point of style, it's usually preferable to use the built-in
> > ordering function and a switch rather than if-then-elses:
>
> Why is it preferable ? Is it shorter/clearer/conciser ... for the programmer ?
> for any reader of the program ? Does the compiler do a better job in the
> generated code ? Are more properties checkable by the compiler ? Are the
> error messages better ?
Using ordering function allows to use generic type T in the predicate
definition (in my original example I had to use avltree(int) because <
and > are only defined on int). As for the switch, I believe it is
mostly a question of style, correct? Even if the produced code is
slightly better, I doubt it really makes much difference while
programming such high-level language as Mercury.
Best regards,
Dmitri.
- Next message: Ralph Becket: "Re: How to fight semideterminism in Mercury?"
- Previous message: Dmitri Soshnikov: "Re: How to fight semideterminism in Mercury?"
- In reply to: Bart Demoen: "Re: How to fight semideterminism in Mercury?"
- Next in thread: Ralph Becket: "Re: How to fight semideterminism in Mercury?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|