From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA01453; Thu, 24 Oct 2002 14:23:03 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA01999 for ; Thu, 24 Oct 2002 14:23:03 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from athlon.baretta.com (host120-68.pool80116.interbusiness.it [80.116.68.120]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g9OCN1D10455; Thu, 24 Oct 2002 14:23:01 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id A39B227250; Thu, 24 Oct 2002 14:34:00 +0200 (CEST) Message-ID: <3DB7E8B8.80200@baretta.com> Date: Thu, 24 Oct 2002 14:34:00 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: it, en MIME-Version: 1.0 To: Daniel de Rauglaudre , Ocaml Subject: Re: [Caml-list] Again on pattern matching and strings References: <3DB73515.90705@baretta.com> <15799.14325.887770.501722@karryall.dnsalias.org> <3DB7A4B9.1030607@baretta.com> <20021024105136.C12351@verdot.inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Daniel de Rauglaudre wrote: > Hi, > > In this case, the is added as keyword in the grammar, > evaluated at parse time, transformed into the > 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 > > 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