caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Michel.Mauny@inria.fr (Michel Mauny)
To: Pierre.Weis@inria.fr (Pierre Weis)
Cc: tarizzo@world-net.sct.fr, caml-list@margaux.inria.fr
Subject: Re: Why no macros in CAML Light ?
Date: Wed, 15 Nov 1995 16:28:25 +0100 (MET)	[thread overview]
Message-ID: <199511151528.QAA15714@pauillac.inria.fr> (raw)
In-Reply-To: <199511150936.KAA08832@pauillac.inria.fr> from "Pierre Weis" at Nov 15, 95 10:36:47 am


> > 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




  reply	other threads:[~1995-11-15 16:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-11-14 23:43 Tarizzo Martial
1995-11-15  9:36 ` Pierre Weis
1995-11-15 15:28   ` Michel Mauny [this message]
1995-11-15 17:02     ` Vale'rie Me'nissier-Morain
1995-11-16 13:00       ` U-E59264-Osman Buyukisik
1995-11-15 17:43     ` Christophe Raffalli
1995-11-15 13:44 ` U-E59264-Osman Buyukisik
1995-11-15 20:23 Hubert Canon
1995-11-15 20:33 Doug Currie, Flavors Technology, Inc.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199511151528.QAA15714@pauillac.inria.fr \
    --to=michel.mauny@inria.fr \
    --cc=Pierre.Weis@inria.fr \
    --cc=caml-list@margaux.inria.fr \
    --cc=tarizzo@world-net.sct.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).