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

[doug.auclair at logicaltypes.com]

Dear Ralph, thank you for your reply.  You wrote:

>We've discussed your op/3 extension in the office and we have some
>reservations that make us reluctant to add it to the repository, at
>least for 0.13.

If your reservations are unshakeable, then, there it is.  Otherwise,
if your objections have reasonable, acceptable, answers, then please
consider op/3 declarations once more.  To wit:

>The main objections are:
>- lack of demand (just one request, so far!), coupled with unfortunate
>   experiences using Prolog code in the past that has used op/3;

These are two objections.  The first, lack of demand, is already
answered (yes, I'm the only one calling for this addition, but that
does not mean that others would find it useful. Micheal at
yeslogic.com may have wished to use op/3 declarations, but, not having
the ability pushed forward using what he had available -- just a
conjecture.  If it helps, I can have two other companies request op/3
declaration functionality for Mercury ... would that make it a
majority of commercial users requesting this feature?); but, I walked
through at least two revisions of dead code in the compiler attempting
to add op-like declaration syntax, so, actually most of my revisions
will be helpful in that it cuts away this dead code.  This code points
to a need being addressed by the Mercury team.  I had that very need,
so I completed the implementation.

The bad experience from Prolog using op/3 was what?  If it was caused by
the declaration's global extent, then my module-only extent implementation
solves this problem.  This ties into the next objection.

>- lack of orthogonality and code maintenance problems, since the same
>   syntax in different modules now has to be carefully checked to see
>   that it parses the same way (e.g., if the modules have differing op
>   declarations for the same symbol); and

As this implementation of op/3 is module-only extent this "problem" is 
permitted, but only insofar as the operator is not defined already in
the operator syntax from Mercury itself (i.e. an op/3 declaration CANNOT
override syntax defined by Mercury (for example, syntax already defined
by library/ops.m)).  This op/3 implementation was intentionally designed
this way -- we have modules that define a set of syntax to address a certain
problem set, but in another module, dealing with another problem set, we use
some of the same operators differently because the semantics of the problem
itself is different.  In Prolog, depending on the implementation, this
causes issues, even though the problems are clearly separated across
modules.  This implementation of op/3 declarations for Mercury
addresses that problem in a safe manner.

>- we are planning on moving the compiler to use a new yacc-style parser
>   in the not-too- distant future and it's very unclear how we'd make
>   that change if we also support dynamic syntax changes, a la op/3.

Hm! So, does this mean that library/ops.m is deprecated?  That the
declarations there will be ignored in future compiler releases?  That
library/parser.m/read_term_(from_string_)with_op_table will become
obsolete?

If so, then, yes, op/3 declarations could gum the works.  If not, then
there may lie an misunderstanding of what the op/3 declarations do:
the syntax /ADDITIONS/ (neither deletions nor alterations) to a /MODULE/
(not globally) occur /AT COMPILE TIME/ (not 'dynamically').  The
underlying internal representation of parsed op/3-enhanced syntax is
equivalent (if not identical) to the internal representation of
standard Mercury.  If library/ops.m remains in force after the planned
parser change, then the changes to allow op/3-declarations should not
be an issue.

-----

The above are my answers to the stated objections.  If not
satifactory, then, of course, op/3 declarations are off the table for
release 0.13.  But I urge otherwise for two reasons: 1) the dead code
supporting hooks for a planned op/3-like declaration set are already
gumming up the compiler works (since nobody else uses those hooks then
replacing them with mine: first causes no harm -- primus non nocere,
and second actually replaces void functionality with useful
functionality), and 2) funding: once our contract gets turned 
full on, we are going to need commercial support.  As Zoltan discussed
with me, that company providing the support is probably going to be
very closely affiliated with the Mercury team, which means, that since
part of the commercial support for Logical Types will be the maintenance
of the op/3 declaration functionality, two versions of Mercury must be
maintained (one for Logical Types, one for all other users) which I can
relate from personal experience is tedious at best.  Rolling in op/3
eliminates the disconnect that will occur when assisting the
supporting company address issues we raise.

So, back to my original request.  If my answers to the objections are
satisfactory, please include op/3 in release 0.13.

Thank you.

Sincerely,
Doug Auclair
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------