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

[Ralph Becket]

doug.auclair at logicaltypes.com, Thursday,  2 March 2006:
> >An alternative approach to dealing with this issue is to implement a
> >preprocessor that exists entirely separately of the compiler.  It would
> >parse the module items exactly as your modified version of the parser does,
> >and then spit out items with all user defined operators in non-operator
> >form (and make liberal use of `:- pragma source_file' and `#line'
> >directives so that error messages are reported correctly).
> 
> This is absolutely the worst way to go about things.

Why?  Preprocessing files prior to compilation (which is a very common
thing to do) is easy.  It would also mean you get what you want without
having to patch the compiler.

The term parser module is not going to go away and it would be trivial
to do.  All you'd have to do is rebuild the tool when you install a new
version of Mercury with an amended operator list.

As to the readability-of-code issue, it *is* a problem.  You only have
to look at requests for help on comp.lang.prolog that use user-defined
operators to see how hard it is to understand such code when you're not
familiar with it.  (Just because it may be possible to use op/3 well,
doesn't mean that's how it generally will be used.)

Another reason I am unconvinced about supporting op/3 is that on the
rare occasions I do have to make changes to the operator list, I find it
nigh on impossible to get the associativity and precedence right without
a good deal of trial and error (just looking at the operator table
doesn't help, at least for me: I have to try things out and see what the
parser actually does before I'm half-way convinced I've got the
parameters right).  I therefore have little confidence that I will be
able to follow a file written using op/3 with anything like the ease
that I otherwise would.

In order to convince us that op/3 is a good idea you have to lay our
concerns to rest, which is just what any developer has to do with a new
proposal.  A good place to start is with some examples showing (a) how
op/3 makes programs much easier to read (and that using vanilla syntax
makes them much harder to read) and (b) why preprocessing is a terribly
bad idea.

Cheers,
-- Ralph

p.s. I just want to reiterate a point Mark made: this discussion process
is what all new ideas have to go through before possibly being accepted.
What makes it sound worse is that with syntax proposals, everybody has
an opinion and, usually, few people agree with each other!
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------