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

[Ralph Becket]

Peter Schachte, Friday,  3 March 2006:
> 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?

No, I meant for Doug's purposes, where the extent of an op/3 directive
extends to the end of the file and no further, and certainly not into
importing modules.

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

Of course, it's even easier if you think of a textual name and stick
with the usual convention...

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

In Doug's method, every file that wants to use the new syntax has to
duplicate the op/3 directives.  This is no different.

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

No, you preprocess the files to get .m files, then all tools work with
those.

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

I meant, "when the Mercury language operator list is amended".

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

Big deal.  If you want to do something wacky with the syntax, you should
expect to pay a small price.

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

Why didn't you just call '***' something like `db_trace' instead?

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

What I was suggesting was that Doug write a general purpose
pre-processor using the Mercury term_io library which would work like
this:

	repeat until EOF
		read in term from source file using own operator table
		if term = op/3 then
			update operator table
		else
			write out term in canonical form to target file
			(prepending #file and #line directives as
			appropriate)

And that's it.  It would take me about an hour to get this right, at the
outside.

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