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

[Ralph Becket]

Peter Schachte, Monday,  6 March 2006:
> 
> Not a straw man; you missed my point.  You're looking at my finger,
> rather than where I'm pointing.  Since you wouldn't give me an example
> of where user-defined operators could disadvantage the reader, I took
> this as an example of how operators can be confusing.

It's a good argument in favour of *not* having a precedence-based
grammar for non-expression terms.

> If the user
> wanted to develop some complex functionality, they might come up with
> new operators giving a syntax something like your example.  You were
> arguing that this syntax is hard to read.  I agreed, but pointed out
> that it's even harder to read without operators.

I still haven't seen any examples where user-defined operators would so
radically improve the readability of code that I might be tempted to
reconsider my position.

> I addressed this in my earlier message.  Sure, operators can interact
> in confusing ways.  But overall this doesn't hurt readers because:
> 
> 	1) Operators developed together are designed to be?used
> 	   together, so they read well together.

I nearly end up pulling out what remaining hair I have whenever a
student comes to me with a Brato-esque Prolog program for reasoning
about knights and knaves or somesuch.  It's pleasant enough to read,
but it's a cow to debug.

> 	3) On the rare occasions when there is a genuine ambiguity,
> 	   how hard is it really to look at a couple of op
> 	   declarations to figure it out?  

Well, yes - see Mark's signature-with-type-class-constraints example.

> 	4) If that ever really became a problem, it wouldn't be hard to
> 	   write a tool that reads in code and writes it out with just
> 	   the standard Mercury operators.  Ralph could knock one
> 	   together in an hour.

I have such a tool that I've had to use every time we've considered a
change to the operator table (in fact, that's why I wrote it in the
first place).

> 	5) Most importantly, any small inconvenience is amply offset
> 	   by the benefit of being able to *read* the usual uses of
> 	   the operators.  Since operators are mostly for the benefit
> 	   of the reader, they wouldn't be used if they didn't make
> 	   their common case easier to read.

We could go further and consider allowing arbitrary user-defined
BNF grammar extensions.  The idea of that gives me the heebie jeebies.

> 	6) Some constructs are just too complex and messy to read (or
> 	   write) without operators.  Doug^H^H^H^HPeter's motivating
> 	   example is like that, though he can't divulge it.

Which, you must agree, is therefore less convincing!

> 	   So the
> 	   final benefit for readers is that they sometimes get to
> 	   read better programming abstractions than they would
> 	   without operators.

But is the increase in readability so significant that it outweighs the
potential problems?

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