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

[Peter Schachte]

On Mon, Mar 06, 2006 at 12:33:08PM +1100, Mark Brown wrote:
> On 06-Mar-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> > On Sat, Mar 04, 2006 at 02:47:48AM +1100, Mark Brown wrote:

> > > :- some [T] impure pred foo(S::in, T::out) is det => baz(T) <= bar(S).
> > But without understanding
> > these things, I couldn't read it any better without operators:
> > 
> >    :-(some([T],impure(=>(pred(foo(::(S,in),::(T,out)),det),baz(T))),bar(S))).
> 
> This is a straw man.  We're not proposing to remove operator syntax; the
> choice is between a fixed operator table defined in one place
> (in library/ops.m) and a dynamic operator table defined all over your
> program

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

> > understanding a piece of code
> > requires understanding the constructs it uses.  If it is expressed
> > with operators, that's just one extra thing you need to know.
> 
> Predicates and functions have
> a meaning that is independent of the context in which they are used,
> whereas the precedence of an operator is meaningless on its own

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.

	2) Operators developed separately don't come together very
	   often, and when they do, syntax and type errors catch
	   most errors, so readers don't usually see them.

	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?  

	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.

	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.

	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.  So the
	   final benefit for readers is that they sometimes get to
	   read better programming abstractions than they would
	   without operators.

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