[m-dev.] 0.13 release: op/3 syntax
Peter Ross
pro at missioncriticalit.com
Fri Mar 3 12:45:16 AEDT 2006
On Thu, Mar 02, 2006 at 05:20:27PM -0800, Peter Hawkins wrote:
> Hi...
> Peter Schachte wrote:
>
> >My argument in favor of user-extensible syntax is:
> >
> > a) Users want it; operators have been pretty popular in
> > Prolog.
> >
> >
> >
> I think I'll chime in with a "me too". This came up with the BDD library
> --- often it would be nice to define new operators motivated by the
> mathematical notation rather than use verbose descriptions of what the
> operators do, or to try to overload one of the existing operators with a
> new meaning. Naturally this would require that operators be exportable
> from modules since that's the whole point.
>
In the xml combinator parser module that I implemented operators would
have been very handy. I would also want the operators to be exportable.
/> is a lot more concise then `'/>'` as I currently have to write.
I personally think the `` notation works quite well most of the time,
and where possible I confine myself to using it, but the above example
shows to me where it can be a bit to verbose.
There are two ways to abuse the operator syntax, overriding an operator
to do something completely different. This is already possible in
Mercury. I can already easily define a version of + which does
subtraction when give two integers. So this is already an issue
with the current system.
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. This means that for all the global operators
it would be forbidden to override these fields.
Of course the issue becomes how do you resolve two different libraries
which define the same operator but with different priorities and
associativities.
So finally we are left with the ability to define new operators like
/>. I can't see how this would hurt.
Just my two cents.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the developers
mailing list