[m-rev.] for review: improvements for library/ops.m

[Fergus Henderson]

On 04-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 
> On 04-Nov-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 04-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > 	Move some items which are really just implementation
> > > 	details to a less prominent position in the interface.
> > 
> > This bit I'm not quite so happy with.
> > 
> > Firstly, I don't consider those items to be implementation details.
> 
> They aren't used in the interface to the ops_table.

Yes, but the ops_table is only part of the interface.

> > If you want to order it differently, the module's interface could be
> > divided into three sections:
> > 	- one for the stuff about the different kinds of operators
> > 	  (ops__specifier, ops__class, ops__assoc, and
> > 	  ops__op_specifier_to_class).
> 
> > 	- one for the stuff about operator priorities
> > 	  (the ops__priority type and the ops__max_priority predicate --
> > 	  which, incidentally, ought to be a function now...)
> 
> I think ops__max_priority is related to the operator table -- if we allowed
> user-defined operator tables, there would be no reason to restrict them
> to the same range of priorities as the Prolog operators.

Well, there would be a reason -- historical precedent.
Prolog allows user-defined operators, but doesn't allow
them to have priority greater than 1200.

So `ops__max_priority' was intended to mean the highest allowable
priority, not the highest priority that happens to occur in the table.
If the latter had been the intent, then it would have taken
`ops__table' as a parameter.

In other words, as originally designed, it is a property of the
ops__priority type, not a property of the table; hence it should be
defined with the type, rather than the table.

Now, it might be a good idea to revisit this design at some point.
If we do decide to allow arbitrary priorities, then it would make
sense to add an `ops__table' parameter to `ops__max_priority'
and to move it from the `ops__priority' section to the
`ops__table' section.  We'd also need to modify the code in
library/parser to handle priorities greater than 1200.

But there would not be much point doing that without also adding
support for user-defined operator tables.  I don't think it's worth
the hassle right now.

In the mean time, I'd rather the design stay coherent,
which means that as long as `ops__max_priority' doesn't
take an `ops__table' parameter, it should go with the
`ops__priority' type, rather than in the `ops__table' section.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------