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

[Peter Schachte]

On Fri, Mar 03, 2006 at 09:22:21AM +1100, Ralph Becket wrote:
> 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.
> > 
> > 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.

Because it doesn't work.  If module a imports b and c each of which
introduce new operators, which preprocessor do you run first, the one
that can handle a's operators, or the one that can handle b's?  And
what does it do when it sees uses of the the other module's operators?

And because it's a PITA to write a whole preprocessor just because you
decide you want to add, say, ** as a new infix operator.  It's not
that it's so hard, but it's it's a lot harder than putting in some op
declarations.

And more importantly because it makes a mess of any module that wants
to use the operators.  You can't just do make foo.depend or mmc --make
foo anymore.  You have to build a separate executable just to parse
your module.

And because then you need some way to tell any other tools that read
Mercury source files that they, too, have to preprocess the file
before they can even parse it.

>  All you'd have to do is rebuild the tool when you install a new
> version of Mercury with an amended operator list.

But it's not the Mercury language that has an amended operator list.
Each module may define operators that it expects its clients to use.
That module, I argue, should just have to document what its operators
are and how to use them (including precedence relative to other
operators).  With Doug's file-local operators, the module will also
have to list the op declarations you have to insert into all your
modules that want to import that module.  Not very nice.  But your
proposal requires them to also tell you what mess you have to put in
your Mmakefile, and what you have to do to get it to work with mmc
--make.  (For that matter, can mmc --make work with preprocessors at
all?)

Here's an example of how I've used operators.  The recent discussion
of logging reminded me of this one.  When I was debugging the Quintus
debugger, I found it difficult to figure out what was going on, and of
course I couldn't use the debugger to debug it.  So I defined a prefix
operator *** and inserted it at the beginning of goals that I wanted
to trace.  Then I defined a predicate ***/1 something like:

	***(Goal) :-
		(   write('call ')
		    write(Goal),
		    nl
		;   write('fail ')
		    write(Goal),
		    nl,
		    fail
		),
		Goal,
		(   write('exit ')
		    write(Goal),
		    nl
		;   write('redo ')
		    write(Goal),
		    nl,
		    fail
		).

I knocked it together in a few minutes, and it was very useful in
debugging.  I found it very easy to insert and remove *** at the
beginning of lines in the source code, and they didn't disturb my
reading of the code.  Sure, I could have written a preprocessor, but
it would have taken a lot longer, and I don't think I would have
bothered.  And I could have used normal syntax like debug(Goal), but
that would have been more difficult to insert and remove, and would
have made it much harder to read the real code.

-- 
Peter Schachte              Victory attained by violence is tantamount to a
schachte at cs.mu.OZ.AU        defeat, for it is momentary.
www.cs.mu.oz.au/~schachte/      -- Mahatma Gandhi 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------