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

[Peter Schachte]

On Fri, Mar 03, 2006 at 09:17:27PM +1100, Mark Brown wrote:
> there are many aspects of the
> Great Purity War which I'm reminded of in the current debate.
> As I recall, the early part of the battle was getting over the negative
> stigma of "impurity" and looking at things objectively.

Nice analogy.  What seems familiar to me is that much of the current
debate comes down to a fear of the unkown.  If op/3 is added, will
pandemoneum break out?  Will Mercury start looking like APL?  Or,
worse, Perl?

I suspect most Mercureans have less experience with Prolog than
Haskell, which doesn't allow its syntax to be extended (just the ugly,
inflexible backtick notation).  So it's not surprising some find the
prospect of user-defined operators frightening, nor that reassuring
words from a few who have experience with them are greeted with
skepticism.  The only problem *I've* had with operators in Prolog was
the way they interacted with files and modules.  Prolog got that badly
wrong, and I argued that when I was at Quintus, too.  But I worked out
how Prolog could have implemented them correctly (the key is for
Prolog to remember the operators *added* by a module), and the problem
is much easier in Mercury, since it doesn't have an interactive
environment.  There's not much else I can say to convince anyone
beyond urging you to poll Prolog users.

> Getting back to the present debate: the concern for readers of Mercury code
> is crucial and, despite it being raised on more than one occasion, is one
> that I cannot see has been addressed by advocates of the new feature.

Fair enough; the needs of readers are important.  My basic argument is
that in order to read a piece of code, you need to understand the
types, functions, and predicates it uses.  That means you have to read
the documentation for those things, and that documentation will also
include any operators defined.  The operators are not a huge new
complexity waiting to trip you up.  They're just one small part of
what you have to understand, along the lines of the order of arguments
of some binary pred or func.

I was going to try to address your fear by giving an example (using
'in' as in infix operator for set/list membership) where I think an
operator would make code look nicer without causing the sky to fall
in.  But of course that argument can't help; the reply is just "well
that one looks OK, but about other uses?"  I can't prove the absence
of a problem no one knows about.  So let me throw it back at you:  can
you think of a specific way programmers might use operators in good
faith that would cause problems for readers?  The good faith part is
important:  remember, people only define operators to make code
*easier* to read.

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