[m-rev.] Re: for review: fix bug in write_term

[Mark Brown]

Hi Doug,

On 06-Mar-2006, doug.auclair at logicaltypes.com <doug.auclair at logicaltypes.com> wrote:
> Dear Mark (I don't have access to mercury-reviews, so I'm responding just
> to you.  If a propos, please forward this email to that maillist),

I've CC'd mercury-reviews, and included all of your message.

> 
> Thanks for putting in this fix, along with the regression tests, for review.
> I do have an issue with capping the max precedence to 999.  In Prolog, more
> than a few operators have precedences greater than 999: notably ';' (1100),
> '->' (1050), the binary and unary ':-' (1200) and the DCG relation '-->'
> (1200).  The latest docs of the mercury compiler distribution have these
> precedences for these operators, and library/ops.m still has these
> precedences for these operators set to these (greater than 999) values.

Just a bit of explanation of the change.  The max_priority remains at 1200
as it was before; it's the arg_priority which has been changed -- this
parameter relates to the comma that appears in argument lists, and also the
commas that appear to the left of the `|' in list syntax.  It is one less
than the effective priority of such commas.

ISO Prolog (if I'm not mistaken) says this priority should be 999, which I've
now set it to.  In other words, the comma appearing in argument lists has
effectively the same priority (1000) as the comma operator.

The practical effect of the parameter is that any operator appearing as
an argument will need to be parenthesised if its priority is greater than
999.

The Mercury parser, before this change, was more lenient with requiring
parentheses, for both reading and writing terms.  This allows, for example,
'::'/2 to be used without parentheses.  As you observed, however, some terms
can be written out incorrectly (namely, those involving braces and/or list
syntax).  The change I made was to retain the leniency when reading terms,
but not when writing them.  As a result, sometimes _more_ parentheses will
be written than strictly necessary, but this of course is much better than
_less_!

> 
> Is there an issue with declaring the greatest precedence to be something
> other than it is (the lang ref man has operators with precedences maxing
> at 1200)?  I know that changing the precedence of the operators 
> enumerated above would certainly throw into confusion the users coming
> from a Prolog background.

Yes.  I wanted to avoid any changes to our operators, and also any changes
to how terms are read in (even if the behaviour is technically incorrect).
Preserving the incorrectness when writing terms is not important, though.

The change is committed to the repository now, and should appear in the
next ROTD.  Please don't hesitate to let us know if it doesn't fix the
problem you reported.

> 
> Sincerely,
> Doug Auclair
> 

Cheers,
Mark.

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