[m-dev.] Re: user-defined operators

Peter Schachte schachte at cs.mu.OZ.AU
Sun Jul 11 01:15:14 AEST 1999


On Sat, Jul 10, 1999 at 04:20:04PM +1000, Fergus Henderson wrote:
> > I think what I'm
> > suggesting [providing a command to read a file as a list of terms
> > or items] would work for the most common applications that want to
> > read code.
> 
> I think preprocessors of various kinds, all of which add some additional
> language syntax, are probably the most commonly desired application.

what I've always wanted when writing preprocessors like this was to
add some additional semantics, really, more than syntax.  Take global
variables as a representative example.  For this, you need to add $
and := as operators, but that's easy.  Then you just need to read in
an entire module, analyze it, transform it, and then get the
transformed code compiled in place of the original code (you'd want to
generate a separate file and invoke mcc on it, while I'd want this
whole process to be happening inside mcc, and just feed the
transformed code to it as if it came straight off the disk).  Anyway,
reading the entire file as a list of terms or items would work fine
for this.  Items would probably be better.

> What other applications are there?  Pretty printers, compilers,
> program analysis tools.  But most of these kinds of things will be
> supplied with the Mercury distribution anyway -- users generally won't
> want to write such things themselves, IMHO.

Generally not.  Nor will they want to write library modules.  But 1)
you won't be able to supply every such preprocessor people will want,
so it should be as convenient as possible for them to do it themselves,
and 2) the preprocessors you do supply have to be written using some
file-reading interface.

> > Anyway, this example would be better handled with cpp.
> 
> Using cpp for languages other than C is a really bad idea, for reasons which
> I can explain in detail if you don't believe me.

I don't think it's so crash-hot for C, either (I hate that you can't
define/redefine macros within macro definitions!  Inconceivable!).  I
figured it would be good enough for conditional compilation for
Mercury, but if not, it would certainly be easy to write a specialized
little program that would handle this.  Maybe something like this
should be built into mcc?  Compile-time configuration of Mercury
applications (eg, choosing between set representations, or definition
of a few site-specific string constants) isn't very smooth right now.
Unless there are some tricks I don't know about?


-- 
Peter Schachte                     A person cannot do right in one
mailto:schachte at cs.mu.OZ.AU        department of life whilst attempting to
http://www.cs.mu.oz.au/~schachte/  do wrong in another department. Life is
PGP: finger schachte at 128.250.37.3  one indivisible whole. -- Mahatma Gandhi 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list