term_expansion (was Re: Microsoft Common Lisp?)

[Peter Schachte]

Sorry, but I just couldn't let this statement go unquestioned....

On Thu, 13 Feb 1997, Fergus Henderson wrote:

> Mercury does not have ISO Prolog's preprocessing (term_expansion),
> although it's quite easy to do preprocessing as a separate step, and
> the GNU make based Mercury build environment can handle this quite easily.

They handle it, but I certainly wouldn't say they do it "quite
easily."  The absence of such transformations, despite the many
obvious applications, serves as evidence that it's not so easy.  There
are three ways that Prolog's term_expansion makes this easier than it
is in Mercury:

    1.  Prolog takes care of reading the source file for you, and
	there's no need to write a transformed file, either.  Mercury
	could fix this with a higher-order library predicate that
	takes two file names and a predicate, and reads the first file
	into a data structure, passes this data structure to the
	predicate, gets a transformed data structure back from the
	predicate, and then spits it out into the second file.

    2.  term_expansion doesn't require users to monkey with Makefiles
	to get their programs to work correctly.  There are some
	subtleties for Prologs that support separate compilation of
	source files to object files (as Mercury does), though.  I
	don't think this should be underemphasised.  Right now,
	Mercury will generate your Makefiles for you, and will even
	keep the dependencies correct.  This is a *major* improvement
	over C.  But Mercury requires the implementor of a language
	extension to have to explain to their users that they'll have
	to name their source files with a different extension than .m,
	and then edit all their Makefiles to put in a rule that
	transforms files with this extension into .m files by invoking
	a translator.  This throws away the hard-won simplicity of
	Mercury's module/mmake system for language extensions.

    3.  term_expansion handles, though not a smoothly as one might
	like, the use of multiple languages extensions in the same
	file, while simple make rules won't.  And yes, this *will*
	happen.  For example, someone will want to put their lexer and
	parser for a simple language in the same file, and each will
	be implemented as a separate translation.  Or they'll want to
	use some other transformation (e.g., named term fields with
	accessors and setters, or hidden argument threading) in
	implementing their parser.  Anyway, when this happens, the
	poor user will have to craft their own make rules to get it to
	compile.

The Mercury solution will work, but it's certainly nowhere near as
easy for the implementor (and documenter!) of such a translator, nor
for the user, as Prolog's term_expansion approach.

On the other hand, last I heard ISO Prolog didn't have term_expansion
either, although most Prologs do.


-Peter Schachte      URL:  http://www.cs.mu.oz.au/~pets/
pets at cs.mu.OZ.AU     PGP:  finger pets at 128.250.37.150 for key
    [A computer is] like an Old Testament god, with a lot of rules
    and no mercy.  -- Joseph Campbell