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

[Mark Brown]

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:
> > On 04-Mar-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> > > in order to read a piece of code, you need to understand the
> > > types, functions, and predicates it uses.  The operators are 
> > > just one small part of what you have to understand
> > 
> > No, they are an entirely different kettle of fish.
> > For functions and predicates, all you need to know is the meanings of the
> > names.
> > For operators, the context is important.  You need to know the relative
> > precedence of an operator with respect to those around it.
> 
> > :- some [T] impure pred foo(S::in, T::out) is det => baz(T) <= bar(S).
> 
> Egads!  The left and right facing arrows here are cute, but not
> terribly intuitive.  I agree operators don't help much in this case,
> but perhaps a different operator design would have been more readable
> (and avoided the need for parentheses).
> 
> I don't understand this declaration because I've never really
> understood existential types very well, and I haven't used type class
> constraints enough to really remember the syntax.  If I could be
> bothered to read up on this, and assuming the intent is clear without
> the parentheses, I could parenthesize it.  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))).
> 
> I probably got it wrong, but the parens all balance.  Does that look
> better to you?  Certainly not to me.  Now to read it you have to
> carefully match parentheses and count arguments to see what's what.
> With operators, the operators should tell you what's what (once you
> understand the construct you're using).

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, with different parts of it applying to different modules.

> 
> The point I keep trying to make is that 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.

I've already addressed this point above.  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 -- it
only has significance in its relationship with the precedence of other
operators.

We support the needs of programmers who want to understand these
relationships by having the entire set of operators defined/documented
in one place.  Allowing op/3 declarations would take this away from them.

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