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

[Peter Schachte]

On Mon, Mar 06, 2006 at 04:17:40PM +1100, Ralph Becket wrote:

What is this, a tag-team wrestling match?

> Peter Schachte, Monday,  6 March 2006:
> > 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.

That too.  A proper grammar-based parser would probably better.  But I
would still ask to be able to extend the grammar at compile-time.

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

How about the several Mercury langauge features added in the last few
years that are just syntax extensions?  Or see my last paragraph
below.

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

Oh yeah, but Newbie code is always dreadful.  Let's agree that newbies
should have to earn a license before adding op declarations.  But if
we omitted every feature newbies could screw up, there wouldn't be
much of Mercury left.

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

The problem with that example for me is that I don't understand what
it means.  If I knew what the parse tree was supposed to be, it would
be easy enough to achieve it.  The operators aren't the problem, the
construct is.  And anyway, this is a problem for the writer, not the
reader.  I thought we agreed the needs of the reader outweigh the
needs of the writer?  But go ahead and rewrite Mark's example for us
without using operators and see who would prefer to read it that way.

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

OK, here's another example.  It'd be nice if Mercury had list
comprehensions.  See if you can write a nice powerful list
comprehension library without using operators.  How readable is the
code that uses it?

-- 
Peter Schachte              We cannot accept that a state assumes the role
schachte at cs.mu.OZ.AU        of the world's policeman.
www.cs.mu.oz.au/~schachte/      -- Nelson Mandela 
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
--------------------------------------------------------------------------