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

[Joris Welkenhuysen]

Peter Schachte wrote:
> 
> On Tue, 18 Feb 1997, Fergus Henderson wrote:
> > Ok, how about the following technique?
> > It seems to address most of your concerns in points 2 & 3 above.
> >
> >       GET_PREPROCESSORS = sed -n '/^%%% PREPROCESSORS = /{s///p;q;}'
> >
> >       %.m: %.pp
> >               @echo "cat $< | `$(GET_PREPROCESSORS) $<` > $@"
> >               @cat $< | eval `$(GET_PREPROCESSORS) $<` > $@
> >
> > The sed command searches for the first string of the form
> >
> >       %%% PREPROCESSORS = blah ...
> >
> > So, would that satisfy your requirements?
> 
> Almost.
> 
> What I'd like to see is a full-fledged language feature.  Having this
> information in the source file is important, but putting in in a
> comment seems like a strange language design decision.  I'm also not
> sure it would work properly when dependencies and interface files are
> being built.  And it doesn't address the issue of where the
> transformer executable is installed.  Finally, it doesn't admit the
> future use of the more efficient runtime code loading, rather than the
> more expensive source-file-source-file transformation, to to implement
> it.
> 
> Here's a concrete proposal.
> 
> Add new directive to the language:
> 
>         :- transformation Module.
> 
> This would name a module in just the same way as :- import_module does
> (following its example linguistically).  The named module would be
> responsible for defining or importing any predicates necessary to perform
> the specified transformation.  The predicate(s) that perform the
> transformation would be specified in the named module by one or more
> directives of the form:
> 
>         :- transformation_pred(When,Pred).
> 
> Where Pred is a closure pred(T::in, io_state::in, T::out,
> io_state::out) which performs a needed transformation, and When is a
> symbol defining at what syntactic level Pred is called (and thereby
> specifying what type T is).  When could be any transformation_phase from
> the following:
> 
>         simple_transformation_phase ---> file ; predicate ; goal.
>         transformation_phase --->
>                 initial(simple_transformation_phase)
>             ;   type_checked(simple_transformation_phase)
>             ;   mode_checked(simple_transformation_phase)
>             ;   det_checked(simple_transformation_phase).
> 
> In the initial(file) case, T would be a list of items; for
> initial(predicate), it would be a predicate definition; for
> initial(goal) it would be a simple (not conjunction, disjunction, etc)
> goal.  For the type_checked/1, mode_checked/1 and det_checked/1
> variants, the types would be similar, but the transformation would be
> performed at later stages of the analysis.
> 
> I realize that all (but possibly the initial/1 versions) will not be
> portable to other implementations of Mercury.  But they are features we
> will need in implementing some of the optimizations we will need for HAL,
> so I'm thinking ahead here.  For starters, just having :- transformation
> and :- transformation_pred(initial(...),...) would be very nice.
> 
> I wouldn't mind implementing this.
> 

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 ?

(I must admit that I haven't used Mercury for any real programming
and I haven't studied the language for a very long time, so this
chalenge might be trivial for a real Mercury guru).

It is an important (language) design rule that anything you can't
define clearly isn't very well understood, not even by the author
of the design.

That's why I feel the methods proposed by Fergus, although a little
clumsy, are much better. Anybody understands a simple source to source
translation using filters. The whole Unix system is built on this
concept.

Maybe this is why the transformation stuff is left out of the
ISO Prolog standard : nobody was able to define exactly what it
should do.

JW