Why no macros in CAML Light ?

Why no macros in CAML Light ?

[Tarizzo Martial]

*** French translation follows ***
Hello,

Using LISP-Like language (SCHEME to be more precise), I wonder why there is
no macro facility in CAML. This would provide some syntactic sugar which
could answer some problems or suggestions encountered in caml-list (lack or
improvment of control structure, etc...)

I know that the very simple (and uniform) syntactic structure of lisp
programs permits an easy coding of complex macros, but it would be nice to
have at least in caml the equivalent of what can be found in procedural (and
compiled) languages : C for example. 

Perhaps, there are implementation problems related with the type system of
CAML, but I can't figure out what they are : the only job of a
"preprocessor" is to translate a phrase in core CAML, not to deal with types.

*****
Bonjour,

Utilisant un langage Lispien (SCHEME pour etre plus precis), je me demande
pourquoi il n'existe pas en CAML la possibilite de programmer des macros.
Cela pourrait fournir du "sucre syntaxique" afin de resoudre quelques
problemes ou suggestions rencontrees dans la liste CAML (ajout ou
amelioration des structures de controle, etc...)

Il est vrai que la syntaxe tres simple (et uniforme) de Lisp facilite le
codage de macros complexes, mais il serait agreable de disposer au moins de
l'equivalent de ce qu'on peut trouver dans les langages proceduraux (et
compilables) classiques : C par exemple.

Il existe peut-etre des problemes d'implementation lies au systeme de
verification de types de CAML, mais je ne vois pas trop lesquels : le seul
travail d'un "preprocesseur" est de traduire une phrase en CAML de base,
sans s'occuper des types.

Merci d'eclairer ma lanterne.
*********************************
 Tarizzo Martial
 Prof. Sc Physiques
 Classes preparatoires
 Lycee J MOULIN
 57600 FORBACH

 Email: tarizzo@world-net.sct.fr
        74014.3307@compuserve.com
 Compuserve : 74014,3307
*********************************

Re: Why no macros in CAML Light ?

[Pierre Weis]

> I wonder why there is no macro facility in CAML.

In the past, this have been a very hot subject among the group of
implementors and designers of Caml. I guess this could be the
beginning of a long long flameware again, if we are not very careful
to keep cool!

In brief: there were a very powerful and complex macro facility in
Caml. But this facility is very hard to design if you want to provide
a true separate compilation module system. In effect, you certainly
would like to write your macros in Caml. Moreover, you want to use them
in other modules, and this implies that the {\em compiler} must call
your macros, hence the compiler should load them in core (either in
source code format or in compiled code format). This turns the
compiler into a definitively more complex system since it must be able
to evaluate arbitrary complex Caml expressions and deal with their
special typing and evaluation environment (to achieve this we must write 
an interpretor or a dynamic linker, and embbed it into the compiler).

The main design decision for Caml Light, apart from the ``keep it
simple and stupid'' guideline, was to enforce separate compilation
even if this means to completely abandon the macro facility. Hence
these very simple and handy modules with interface and implementation
files. Hence the complete absence of macros.

> it would be nice to have at least the equivalent of C macros.

No problem with this feature: you just have to write an equivalent of the C
preprocessor (for instance in Caml itself) and make it available to
the community! 

> Perhaps, there are implementation problems related with the type system of
> CAML, but I can't figure out what they could be.

Well, there are no problems with the type system, except that macro
functions will probably have several different incompatible types (for
instance a macro function that transforms an expression into another
expression will have type CAML_expression -> CAML_expression, while a
macro function that transforms a pattern into a pattern will have type
CAML_pattern -> CAML_pattern).

Finally, the problem of macros in Caml is still an active research
area ``in the background'', since it is definitively very powerful and
elegant (and completely safe in conjonction with the type system): I
hope it will be incoporated into Caml someday. In these lines, Daniel
de Rauglaudre and Michel Mauny have designed and implemented a
prototype of a new Caml dialect (we call it Chamau) with a very
powerful ``quotation'' facility, which provides a powerful macro
facility, which is still reasonably compatible with separate compilation.

> *****
> je me demande pourquoi il n'existe pas de macros en CAML.

Ca a existe' dans le passe'! Le proble`me c'est que les macros se
marient mal avec la compilation se'pare'e. En effet le compilateur
doit pouvoir appeler et charger vos macros ``au vol'', ce qui signifie
qu'il doit ge'rer un environnement spe'cial pour ces macros et
contenir un e'valuateur ou un chargeur dynamique de code.

Pour Caml Light, l'ide'e a toujours e'te' de privile'gier la
compilation se'pare'e et la simplicite'. C'est pourquoi le syste`me de
modules est simple et puissant, et les macros ont disparu.

> il serait agreable de disposer au moins de l'equivalent des macros C.

Il n'y a pas de proble`me pour cela: il suffit d'e'crire un
pre'processeur et de le rendre disponible a` tous.

> Il existe peut-etre des problemes d'implementation lies au systeme de
> verification de types de CAML, mais je ne vois pas trop lesquels.

Non pas de proble`mes, si ce n'est que les macros changent de type
selon les objets auquels elles s'appliquent, expressions, patterns,
de'finitions.

En conclusion, le proble`me des macros est toujours un actif sujet de
recherche dans notre projet, parceque c'est vraiment puissant et
e'le'gant (et su^r avec le syste`me de types de Caml): j'espe`re que
nous en aurons a` nouveau dans Caml un jour prochain. Par exemple Daniel
de Rauglaudre and Michel Mauny ont imple'mente' un dialecte de Caml
(Chamau) qui pre'sente un puissant me'canisme de ``quotation'' qui
permet des macros compatibles avec la compilation se'pare'e.

Pierre Weis
----------------------------------------------------------------------------
WWW Home Page: http://pauillac.inria.fr/~weis
Projet Cristal
INRIA, BP 105, F-78153 Le Chesnay Cedex (France)
E-mail: Pierre.Weis@inria.fr
Telephone: +33 1 39 63 55 98
Fax: +33 1 39 63 53 30
----------------------------------------------------------------------------

Re: Why no macros in CAML Light ?

[U-E59264-Osman Buyukisik]

Why not just use the c preprocessor itself? or m4?  I tried 
gcc -x c -E -P -DDOS foo.z > foo.ml 
and it works. The file had #ifdef/#else/#endif, #define and caml-light list.ml
file in it. Not like the lisp macro facility but it is already available.

Regards,
Osman

Re: Why no macros in CAML Light ?

[Michel Mauny]

> > I wonder why there is no macro facility in CAML.
> 
> > it would be nice to have at least the equivalent of C macros.
> 
> No problem with this feature: you just have to write an equivalent of the C
> preprocessor (for instance in Caml itself) and make it available to
> the community! 

Even simpler: use the C preprocessor itself! (with the -P option)
I know, it is tractable only under Unix, and using Makefiles...

> > Perhaps, there are implementation problems related with the type system of
> > CAML, but I can't figure out what they could be.

> Finally, the problem of macros in Caml is still an active research
> area ``in the background'', since it is definitively very powerful and
> elegant (and completely safe in conjonction with the type system): I
> hope it will be incoporated into Caml someday. In these lines, Daniel
> de Rauglaudre and Michel Mauny have designed and implemented a
> prototype of a new Caml dialect (we call it Chamau) with a very
> powerful ``quotation'' facility, which provides a powerful macro
> facility, which is still reasonably compatible with separate compilation.

I would simply say `compatible', not `reasonably compatible'.

By the way, quotations are some concrete way of noting structures such
as abstract syntax trees. For example, writing <<p(x,q(z,t))>> instead of
the binary tree:

        Node("p", Leaf "x", Node("q", Leaf "z", Leaf "t")).

Quotations are just implicit calls to (user-defined) parsers. They
provide some (controlled) syntax extension facility.

Back to the discussion, now.

Just to make it clear, macros and quotations aren't exactly the same
thing. Neither macros, nor quotations cause real separate compilation
problems. (Well, for macros, it depends on the design.)

Both of them are compile-time evaluation (a function call for
quotations -- the function being known by the compiler --, and
arbitrary evaluations for macros). Both of them simply need some good
properties from the compiler.


On the other hand, macros, if implemented with an `eval' function,
need some form of dynamic typechecking. (To make sure that a
macro-evaluation -- that is, an arbitrary expression being evaluated
at compile-time -- returns a piece of program, expression or pattern
or..., according to the occurrence of the macro call in the source.)

For implementing syntax extensions, macros are just the most powerful
tool. That may be too much. Quotations are more restrictive, and more
reasonable as a syntax extension tool (in the sense that one can make
sure, in the design of the quotation mechanism, that there won't be no
dynamic type-checking).

The ultimate solution for syntax extensions, to my opinion, is to have
an extensible syntax. The only problem for that, is that the Yacc
technique isn't powerful enough.

About quotations, interested people may have a look at:

@InProceedings{Mauny-de-Rauglaudre94a,
        author =        "Michel Mauny and Daniel de Rauglaudre",
        title  =        "A complete and realistic implementation of
                        quotations for {ML}",
        booktitle =     "Record of the 1994 {ACM-SIGPLAN} Workshop on
                  {ML} and its Applications",
        page = "70--78",
        month = jun,
        year   =        1994
}

-- 
Michel

Why no macros in CAML Light ?

[Vale'rie Me'nissier-Morain]

> Even simpler: use the C preprocessor itself! (with the -P option)
> I know, it is tractable only under Unix, and using Makefiles...
Furthermore cpp is not 8bits clean but Caml Light is so it would be a
limitation to the expressivity of Caml Light.

V.

Re: Why no macros in CAML Light ?

[Christophe Raffalli]

> Even simpler: use the C preprocessor itself! (with the -P option)
> I know, it is tractable only under Unix, and using Makefiles...

I do it on my mac ....

----
Christophe Raffalli
Dept. of Computer Sciences
Chalmers University of Technology

URL: http://www.logique.jussieu.fr/www.raffalli

Re: Why no macros in CAML Light ?

[U-E59264-Osman Buyukisik]

"Vale'rie" == Vale'rie Me'nissier-Morain <Valerie.Menissier@inria.fr> writes:

    >> Even simpler: use the C preprocessor itself! (with the -P
    >> option) I know, it is tractable only under Unix, and using
    >> Makefiles...
    Vale'rie> Furthermore cpp is not 8bits clean but Caml Light is so
    Vale'rie> it would be a limitation to the expressivity of Caml

Well, cpp worked ok as long as the weird chars (:))are not used in
macros or #define/#ifdef. Unmatched single quotes will produce
warnings but cause no problems. As for m4, quotes may be a problem,
need to be redefined (to what I dont know). BTW cpp is multi platform,
I use it on DOS machines (same command line as unix: gcc -x c -E -P).

Osman

Re: Why no macros in CAML Light ?

[Doug Currie, Flavors Technology, Inc.]

At 6:43 PM 11/15/95, Christophe Raffalli wrote:
>> Even simpler: use the C preprocessor itself! (with the -P option)
>> I know, it is tractable only under Unix, and using Makefiles...
>
>I do it on my mac ....

Not with CodeWarrior :-( which seems to require C syntax in the
preprocessor.  Do you use MPW?

I would like to see a simple macro mechanism in Caml Light (and other ML
languages) to avoid the use of cpp and make.

One possibility... LISP has an intermediate mechanism between preprocessor
and full compiler macros, reader macros. A particular set of reader macros
"#+" and "#-" are useful for the types of things the C preprocessor does. A
simplified description of how they work could work in ML is as follows:

The compiler maintains a list of "features." Interactive user code, or
makefiles, or other mechanisms, may add to the features list -- it is just
an ML list of strings. The reader (lexer) treats the #+ and #- tokens
specially. If the token following the #+ is a string on the features list,
then the next token [expression] is processed, otherwise it is discarded.
If the token following the #- is a string not on the features list, then
the next token [expression] is processed, otherwise it is discarded.

This doesn't require any change to the compiler per se (just the lexer) and
does not require an "eval" mechanism.

For example, to distinguish constants for 32 bit versus 64 bit
implementations, you could use:

let size = #+"32bit" 0x40000000 #+"64bit" 0x4000000000000000

For a function only available in UNIX implementations:

#+"UNIX"
(
let chmod file xxx = ... ;;
)

Or for a function not available on the Mac:

#-"Macintosh"
(
let system str = ... ;;
)

e

Why no macros in CAML Light ?

[Hubert Canon]

> > Even simpler: use the C preprocessor itself! (with the -P option)
> > I know, it is tractable only under Unix, and using Makefiles...
> Furthermore cpp is not 8bits clean but Caml Light is so it would be a
> limitation to the expressivity of Caml Light.


There are other good preprocessors. For instance I use m4, which
exists in a DOS version too.

-- 
-------------------------- Hubert Canon --------------------------
        Email : canon@poly.polytechnique.fr
        WWW   : http://www.polytechnique.fr/poly/~canon/
------------------------------------------------------------------