Browse thread
[Caml-list] Again on pattern matching and strings
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Alessandro Baretta <alex@b...> |
| Subject: | Re: [Caml-list] Again on pattern matching and strings |
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