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

[doug.auclair at logicaltypes.com]

ear Mark and all,

>> Implementation well-tested: done;
>Regression tests need to be provided for the Mercury test suite, covering
>both legal and illegal uses of the feature.

This discussion is a propos to the current debate ('whether op'), but, given
that op/3 /is/ accepted into the language, this particular task is going
to require more effort than standard unit testing.[0]  I have provided some
examples of programs where op/3 works and where op/3 /should not/ (because
the operator declaration is out of scope).  These, of course, are not
sufficient for regression tests, but they do provide the basic rules for
scope of op/3, as I have defined it.

Please note that when I originally submitted the code changes, I did run
mercury-tests-<whatever> before and after the modifications to the compiler.
The test suite had the same result before and after the inclusion of op/3.
This is what I meant by 'primus non nocere' that the change itself did not
perturb the compiler's test suite results.

-----

Back to the debate:

Using op/3 will change the syntax and semantics of a program, and that is
what this current debate is about.  My practical and pragmatic experience
is the following:

        "Using op/3 improves the readability and writability of programs."

And by 'programs' I mean programs used in industry, in production, doing
real things.  Not the:

"I tried op and it broke my program; homework due tomorrow!" accompanied by the
"How do you get the last element of a list" along with the
"How do you write a for-loop in Prolog [or Lisp]" that one sees on
comp.lang.prolog and comp.lang.lisp all the time.

Mercury makes the claim that it should be the premier programming language
for computer industry.  I concur.  And, being in industry, I add that op/3
will help toward that goal and not having op/3 will hinder that goal.

Mark, you put forward a good example of a confusing structure using op.
Can people abuse language features? Rhetorical question, that: I've seen
"Java" code that used switches and if statements nearly exclusively:  here's
an object-oriented programming language with a single switch statement
with 100s of branches and at points seven layers deep (alternately nesting
if's and switches).  I kid you not.

Have people abused op/3?  I, personally, haven't seen it; and I've had
plenty of industry experience (where us hackers and code slingers hang
out, drinking lattes and murderlyzing code), but I'm sure it's been done.

But op/3 is a language feature (in Prolog, and on Mercury's wishlist), and
just like many other language features can be the victim of abuse.  What,
shall we remove list from the language because people (including myself)
have abused it?  Even the lambda-calculus allows one to construct a list
and take the head and tail (easy: V is list, K is head and KI is tail).

For me, syntax mutability is a necessity: I need to shape the language
toward the problem domain until expressing the solution becomes
straightforward, because the solution is stated in the language of the
problem.

For others, it appears the same way.  The two Peters quietly put forward
similar arguments ("When I was doing thing A, syntax B would have been
nice"), and the not-so-quiet Peter (Thank you, sir, sir, and sir, for
stepping forward and stating your views in this debate).

-----

A similar debate frequently occurs over in the Lisp-family over (syntactic)
macros.  There is usually a strident debate where some academic types
fall squarely onto one side or the other in arguing over the merits.  The
industry types watch bemusedly, offering that 25% of the code was written
using macros, and that it would be very difficult to write it otherwise.[1]

I am in no way equating op/3 with Lisp macros, but I am equating the
debates over the merits and the practical, actual, use of this particularly
important language feature.

So, yes, let us debate the merits of op/3 to get a good one into Mercury
(there has been some good discussion about op/3 extent that I've seen); but,
yes, let's get op/3 into Mercury, because in our 1,000,000 transaction-a-day
multi-terabyte data store, (Prolog) production system fully 25.5% of the
production modules and 18% of the test modules use or define operators
with op/3.  In Mercury systems I build, I /will/ need this functionality
to deliver real systems to my real customers.

And I don't have 13 years[2] to wait for the happy ending.  Please, let's come
to consensus expeditiously and put op/3 into the language.

Sincerely,
Doug Auclair

[0] The unit or regression testing isn't going to be all that easy because
a failing or out-of-scope op/3 declaration will cause the compilation
process to quit, hairily.  This is a wee bit harder to process than testing
if a semidet pred exitted successfully.
[1] "Beating the Averages", scan for 20-25%, http://www.paulgraham.com/avg.html
[2] cf. Mark's cvs annotate on wishlist and prog_io.m

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