[m-dev.] op/3, again.

[doug.auclair at logicaltypes.com]

Dear Peter, you wrote so many things!

>Hmmmm.  OK, the Mercury team is never going to allow users to define
>operators, preferring instead for them to be implemented as a
>preprocessor.  And if they're not going to accept op, they're
>certainly not going to accept anything like term_expansion (I know;
>I've argued for it before).

Um, I'm actually going to be using the example term_expansion
provided in (samples/? extras/?).  Zoltan pointed this out to me at
the PADL.  Did you mean term_expansion as a part of the compiler?

>I know work is underway for a looping facility which I imagine will be
>built into the language, but IMHO really should be done as a library,
>again necessarily as a preprocessor.

'Looping facility'? -- describe, please, this is the first I'm
hearing of it.

[snip (multi)preprocessor design]

Oook! Sounds like quite a bit of work.  I do like having mmc control
the preprocessing flow, as you recommend.  Currently ltq preprocesses
a file and then hands the result off to mmc via make.  So, the ltq
maintainer/user needs to know configurations for Makefile and
Mercury.options (as before).  It'd be nice if mmc handled that all...

For multi preprocessing, ordering may be important.  Some domain
specific languages I work with cannot be described with Prolog's
term_expansion and op/3, so I need to string-escape those bits
(requiring they be interpreted, ugh!  That's the cause of my desire
to embed these bits directly into the source, but that's definitely
off topic, I suppose).

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