[mercury-users] DCG expansion and logical connectives

[Ralph Becket]

> I think that is simply due to the relative precedences
> of `=>' and `all' not being what you expect.  You need
> to write
> 
>     ground(functor(_Name, _Arity, Args)) -->
>          all [Arg] (
>                  { list__member(Arg, Args) }
>            =>
>                  ground(Arg)
>          ).

Aha.  I should have spotted that one.

> The current precedence for `all' and `some' is the same as that used in
> NU-prolog.  It seems to cause confusion quite frequently, so I think it
> might well be a good idea to change their precedence. [...]

Well, it's better to make changes earlier rather than attempt them when
the concrete really has set.  Why not try it out as an experiment?  I can't
find a single use of `=>' as a logical connective (aside from code dealing
with typeclasses and existential types) in the compiler or the extras
distribution.  Can we take a straw poll on the mailing list and see if
anyone
has strong feelings on the matter?

> [...]
> 
> The rationale is that in DCGs, the sequence is important, and
> implications are concepts from logic which do not necessarily 
> imply any
> particular sequence.  For `=>', it might be reasonably 
> obvious that the
> sequence is left-to-right, but what about `<=' and (even worse) `<=>'?
> For them the sequence would not be clear.  Even if we did 
> allow it, the
> use of implication in DCGs would be rare, I think, and so many Mercury
> programmers would not be familiar with it.  If the reader has to look
> up the language reference manual in order to understand such a
> construct, then that construct can hardly be said to improve
> readability.  So it's probably going to be clearer to just write such
> code using `,' and `not' so that the sequencing is clear.

Okay, I think you've convinced me.  I wonder whether it would be worth
including a `list of counterintuitive things' somewhere in the
documentation - or even a FAQ.  While there are good reasons for just
about all of Mercury being the way it is, sometimes the explanations 
are subtle and not what one would expect at first.

Cheers,

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