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

[doug.auclair at logicaltypes.com]

... as the op/3 debate rages ...

I will not step in here to discuss the merits of adding, or not adding, op/3
declarations, as there seems to be a merry one going on already.

I will say that I am addressing part deux -- implementation -- differently than
I have before: that is, I have built a system that builds a program from plain
vanilla Mercury files and files enhanced with op/3 syntax.

ltq <Executable> ("Logical Types Quicksilver") simply creates a Makefile from
including mmc -M Executable's output and then executes that Makefile.

That Makefile runs dopp <Args> ("Dynamic Operator PreProcessor") from build/.
dopp simply copies plain vanilla Mercury modules to build/ but also transforms
op/3 enhanced files to plain vanilla Mercury modules in build/.  Then the
Makefile runs 'mmc --make --infer-all Executable'.

(As a side note, Ralph's implementation was the guide, but it was not a
trivial implementation, as it was necessary to reinvent types hidden under
module ops implementation and then create an instance of op_table that
played nicely with the current syntax -- 500 lines total for the entire
build system.  By the way 'ltq' would be superfluous if 'mmc' had an
option that spit out <Executable>.m's dependencies to stdout ... is there
such an option?)

This system, as it replaces the simplest variant of Mercury's build system,
is currently adequate for our needs.  So, for now, I will drop support of
Quicksilver (the Mercury compiler with built in op/3 support), replacing it
with this system.  I will post this on my site (http://www.logicaltypes.com)
for any interested users.

For any interested parties, I do have the Mercury compiler enhanced with op/3
declaration support for sparc.sun.solaris2.8 and powerpc.apple.darwin8.3.
These distributions are available both for 0.12.2 and ROTD-2006-03-01.  I will
no longer post these distributions to my site, so if you want them, email me.

This post is by no means a retreat from my original request, but I do agree
that we should hash out the merits and move forward together for including
it into the compiler.  This debate has brought forward good points.  So, for
the time being, I have developed this alternate approach that doesn't muck up
the compiler (saving me loads of work on each ROTD), but still gets us what
we need.

Back to point un: one of the arguments against op/3 was that only one user
was requesting it.  Myself.  The current debate weakens this argument
considerably; so, in solidarity and thanks, I am assuming a new name.

Sincerely,
"Peter" 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
--------------------------------------------------------------------------