[mercury-users] term_expansion (was Re: Microsoft Common Lisp?)

[Peter Schachte]

On Wed, 19 Feb 1997, Joris Welkenhuysen wrote:

> Peter Schachte wrote:
> > Add new directive to the language:
> > 
> >         :- transformation Module.
> 
> Before embarking on this project, I would like to see a clear and
> somewhat formal definition of these proposed language feature.
> It goes without saying that this definition shouldn't be based on
> any compiler internals. Do you think this can be done ?

Not currently.  The reason is that I don't believe it's a very good
idea to define too precisely the types that all Mercury compilers must
use to represent programs being compiled.  This would tie the hands of
implementors who might have some clever ideas of how to, for example,
implement the compiler more efficiently, or give better error
messages, or implement incremental recompilation.

As with so many questions, Type Classes Are The Answer (TM). Type
Classes are much like "interfaces" in Java: they would allow users to
specify which predicates and functions a type would have to support,
without having to specify the actual structure of the type.  With type
classes, the interface for the types of the terms passed to the
transformation predicates could be specified without specifying the
actual type.  This would allow future implementors to use whatever
type they like, as long as it provides the required predicates and
functions.  For the time being, I would propose to use the term type
for the initial transformations (which work like term_expansion), and
hlds terms for the others.

Formally specifying this, or even just documenting it clearly, will be
quite a lot of work.  I don't want to do it if such an extension
wouldn't be incorporated into Mercury anyway.  So it seems to me at
this stage the questions are:

    1.  Should the ability to transform Mercury programs be part of
	the language?

    2.  Should it be possible for users to write code that involves
	source code transformation in Standard Mercury, or should this
	be outside the language?

    3.  Should programs implemented using transformation be portable
	between different platforms and between different Mercury
	implementations?

If it is decided to put such a feature into language, then we can turn
to the next question:

    4.  What's the simplest, cleanest way to extend Mercury to support
	this in a way that's convenient for transformation users and
	not too painful for transformation implementor, and not too
	painful for Mercury language implementors?
	
Sure, there's only one Mercury implementation at the moment, but I
think it's important to think of the language, not an individual
implementation, or operating system, or platform.

> That's why I feel the methods proposed by Fergus, although a little
> clumsy, are much better. 

I'm not really talking about implementation strategies, but about
language design.  The Mercury compiler can implement it using Fergus's
approach as far as I'm concerned (though of course this won't work for
the transformations I'm going to need that have to be performed after
type, mode, or determinism analysis).  I'd just like to see it as part
of the language.

> Anybody understands a simple source to source
> translation using filters. The whole Unix system is built on this concept.

Not everyone uses Unix.  I wonder how well this would work under
Windows?  VM/CMS?  MacOS?  Sure, some solution could be found on each
platform, but I doubt any one solution would be very portable.  Buy
putting the feature in the language, you leave it up to the language
implementor to do the porting; the users have it easy.  As it should
be.


-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