From: Alessandro Baretta <alex@baretta.com>
To: Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr>,
Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Again on pattern matching and strings
Date: Thu, 24 Oct 2002 14:34:00 +0200 [thread overview]
Message-ID: <3DB7E8B8.80200@baretta.com> (raw)
In-Reply-To: <20021024105136.C12351@verdot.inria.fr>
Daniel de Rauglaudre wrote:
> Hi,
>
> In this case, the <ident> is added as keyword in the grammar,
> evaluated at parse time, transformed into the <expression/pattern>
> depending on its position. The possible parameters are possibly
> substituted by their actual value in the expression pattern.
Does "evaluated at parse time" mean that you define a syntax
tree transformation as opposed to a character stream
transformation? I ask because I'd like this scheme to avoid
the bug-prone interactions between C macros and surrounding
code.
> ...We can have also:
> UNDEFMACRO <ident>
>
> To remove it from the grammar.
This is more or less what I had in mind. The only problem
with this scheme is probably with compile-time error
reporting. If this is not somehow linked with the compiler,
how will the compiler be able to tell us that that something
we wrote makes no sense? If the macro is small and self
evident, this might not be a problem, but if you use such
macros to match, for example, the Epson ESC/P command set,
drawing a connection between a compiler error--reported with
reference to the pure Caml syntax tree--and the
CamlP4-extended source code might be difficult.
In all other respects, this approach seems to be satisfactory.
> Would it be OK? General enough? Other propositions?
>
Thank you,
Alex
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2002-10-24 12:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-23 23:47 Alessandro Baretta
2002-10-23 23:46 ` Alexander V.Voinov
2002-10-23 23:57 ` Stefano Zacchiroli
2002-10-24 7:10 ` Alessandro Baretta
2002-10-24 7:38 ` Stefano Zacchiroli
2002-10-24 8:01 ` Jacques Garrigue
2002-10-24 12:38 ` Alessandro Baretta
2002-10-24 13:24 ` Luc Maranget
2002-10-24 15:13 ` Alessandro Baretta
2002-10-24 16:26 ` Sven Luther
2002-10-25 8:40 ` Luc Maranget
2002-10-24 4:11 ` Christopher Quinn
[not found] ` <15799.14325.887770.501722@karryall.dnsalias.org>
2002-10-24 7:43 ` Alessandro Baretta
2002-10-24 8:51 ` Daniel de Rauglaudre
2002-10-24 9:50 ` Stefano Zacchiroli
2002-10-24 10:30 ` Noel Welsh
2002-10-24 12:59 ` Daniel de Rauglaudre
2002-10-24 13:16 ` Basile STARYNKEVITCH
2002-10-25 10:29 ` Daniel de Rauglaudre
2002-10-24 12:34 ` Alessandro Baretta [this message]
2002-10-24 12:51 ` Daniel de Rauglaudre
[not found] <IIEMJEMIMDMLIIPHPOBLOELNCAAA.fsmith@mathworks.com>
2002-10-24 7:16 ` Alessandro Baretta
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=3DB7E8B8.80200@baretta.com \
--to=alex@baretta.com \
--cc=caml-list@inria.fr \
--cc=daniel.de_rauglaudre@inria.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