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

[Mark Brown]

On 04-Mar-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> 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.

That's not it at all.  I *know* that it is already hard to parse
expressions with a fixed operator table.  I *know* that it is an order
of magnitude harder to parse expressions with arbitrarily extended
operator tables.  I *know* that if I had to read code that used the
same symbol but with different precedence or fixity in different modules
then I would want to throttle someone.  Possibly using some of the rope
that they had been supplied with.

> I suspect most Mercureans have less experience with Prolog than
> Haskell,

That's probably true, and yet most Mercureans would still have had
more bad experiences with Prolog than with 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.

I dare you to tell the Haskell developers that they are afraid of user
defined operators!  Either that or concede that they might have other
reasons for not allowing the syntax to be extended.

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

Right after I ask the French how to win a war.  *grin*

Seriously, see Ralph's earlier observation about comp.lang.prolog.

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

No, they are an entirely different kettle of fish.

For functions and predicates, all you need to know is the meanings of the
names.  Armed with this, and with knowledge of how goals are put together
(applying arguments, conjunction, disjunction, quantifiers, etc), you know
what the semantics of any goal that you can parse is.  The meaning of a
name tells you what you need to know regardless of the context in which it
occurs.

For operators, the context is important.  You need to know the relative
precedence of an operator with respect to those around it.  As a simple
example, in the expression `1 + 2 * 3' you need to know the relative
precedence between the two operators before the meaning of either of
them can help you.  Note that the documentation of the _relative_
precedence exists nowhere.  You have to look at both op/3 declarations
and compare them yourself.

For a more complex case, recall my earlier example:

:- some [T] impure pred foo(S::in, T::out) is det => baz(T) <= bar(S).

In this one, not only does knowing the meaning of each symbol not
help you, but you can't even tell what *category* each of the symbols
belongs to without some non-trivial reasoning about the relative
precedences.  Is '<='/2 a typeclass or a keyword?  Is baz/1 a type
constructor or a typeclass?

The compiler gets terribly confused by the above if you try to use it
as a declaration.  Actually, no it doesn't; it knows precisely which
category each symbol belongs to, because it is much better at parsing
these expressions than most humans are.  But it has no way of knowing
what the user's answers to the above two questions would be, so it
can't give you any help in sorting out your problem.

And this is just using our fixed operator table, where you only have
to look in one place to figure out the relative precedences.  Imagine
if you had to look in five different places.

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

First tell me how to parenthesise that pred declaration.

I'll give you a hint: one set of parentheses will suffice.  That should
reduce the search space a bit.

Cheers,
Mark.

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