[m-dev.] 0.13 release: op/3 syntax

[Peter Schachte]

On Fri, Mar 03, 2006 at 02:45:16AM +0100, Peter Ross wrote:
> On Thu, Mar 02, 2006 at 05:20:27PM -0800, Peter Hawkins wrote:
> > Peter Schachte wrote:
> > >My argument in favor of user-extensible syntax is:
> > >	a) Users want it
> > > 
> > I think I'll chime in with a "me too".
> > 
> In the xml combinator parser module that I implemented operators would
> have been very handy.

What is it about operators and people named Peter?

> /> is a lot more concise then `'/>'` as I currently have to write.

Now that's just silly!  Why doesn't backtick act as a quote in Mercury
right now?  You shouldn't have to write more than `/>`.  Still looks
pretty ugly to me, but certainly not as bad.

> There are two ways to abuse the operator syntax, overriding an operator
> to do something completely different.

This doesn't really have anything to do with operators.  Ad hoc
overloading is possible for any function or predicate, operator or
not.

> The second way is to override the priority or associativity of an
> operator.  This isn't possible at the moment, and my gut instinct
> is that if an operator is already in scope you shouldn't be able
> to change these fields.

Firstly, I'd argue that an op declaration that is equivalent to an
operator already in force should be quietly ignored.  Then you could
define, say + as an operator in both int.m and float.m, and as long as
the declarations are identical, there would be no problem importing
both.  And similarly if the declarations do not conflict, such as
adding a fx op declaration for an xfy operator.

If the declarations do conflict, it's more of a problem, particularly
if the user is forbidden from modifying either module (perhaps they
are maintained by other people).  If you accept my argument that
operators should be exportable, then any module that wants to import
two modules with conflicting op declarations would face this problem.
In this case, I think the best thing the Mercury compiler could do
would be to allow it, replacing the earlier definition.  There should
probably be a warning, though there should also be a way for the user
to declare that they know about the redefinition and disable the
warning (every warning should be disablable somehow in the code that
elicits the warning).  This would allow the user to import the first
module, put in code using the operator as that module expects, then
import the second, followed by use of the operator as the second
module expects.  And if some predicates need to use the operator from
both modules, the code would just have to pick one syntax to use for
both, or else use the normal name-and-args-in-parens syntax for one or
both.  If conflicting op declarations elicit an error, there's nothing
the user can do.

I don't think this will happen very often.  It mostly will come up
when different fields of study use the same operators in different
ways, and some code involves both fields.  Not common.

-- 
Peter Schachte              Victory attained by violence is tantamount to a
schachte at cs.mu.OZ.AU        defeat, for it is momentary.
www.cs.mu.oz.au/~schachte/      -- Mahatma Gandhi 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------