From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id KAA08847 for caml-redistribution; Wed, 15 Nov 1995 10:37:04 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.6.10/8.6.6) with ESMTP id KAA08837 for ; Wed, 15 Nov 1995 10:36:49 +0100 Received: from margaux.inria.fr (margaux.inria.fr [128.93.8.2]) by concorde.inria.fr (8.7.1/8.6.9) with ESMTP id KAA13935 for ; Wed, 15 Nov 1995 10:36:48 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by margaux.inria.fr (8.6.10/8.6.6) with ESMTP id KAA07679 for ; Wed, 15 Nov 1995 10:36:48 +0100 Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.7.1/8.6.9) with ESMTP id KAA13931; Wed, 15 Nov 1995 10:36:47 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id KAA08832; Wed, 15 Nov 1995 10:36:47 +0100 From: Pierre Weis Message-Id: <199511150936.KAA08832@pauillac.inria.fr> Subject: Re: Why no macros in CAML Light ? To: tarizzo@world-net.sct.fr (Tarizzo Martial) Date: Wed, 15 Nov 1995 10:36:47 +0100 (MET) Cc: caml-list@margaux.inria.fr In-Reply-To: <199511142343.AAA28670@world-net.sct.fr> from "Tarizzo Martial" at Nov 15, 95 00:43:04 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: 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 ----------------------------------------------------------------------------