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 WAA30795; Sun, 23 Sep 2001 22:47:54 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA30777 for ; Sun, 23 Sep 2001 22:47:54 +0200 (MET DST) Received: from penguin.housemarque.fi (www.housemarque.fi [212.213.160.98]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f8NKlqn25882 for ; Sun, 23 Sep 2001 22:47:53 +0200 (MET DST) Received: from [192.168.42.66] (helo=frodo) by penguin.housemarque.fi with smtp (Exim 3.00 #1) id 15lG71-0002Fr-00 for caml-list@inria.fr; Sun, 23 Sep 2001 23:44:27 +0300 Message-ID: <004801c14471$741cc400$422aa8c0@housemarque.fi> From: "Vesa Karvonen" To: References: <000b01c143aa$d5218690$422aa8c0@housemarque.fi> <20010922211013.A580@eecs.harvard.edu> <001501c1444c$a7b0a720$422aa8c0@housemarque.fi> <20010923134425.A28129@lakeland.eecs.harvard.edu> <000901c14466$7848e280$422aa8c0@housemarque.fi> <20010923160915.B28129@lakeland.eecs.harvard.edu> Subject: Re: [Caml-list] On ocamlyacc and ocamllex Date: Sun, 23 Sep 2001 23:51:01 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: "Christian Lindig" > On Sun, Sep 23, 2001 at 10:32:23PM +0300, Vesa Karvonen wrote: > I lobbied for this three years ago and had a patch for ocamllex: > > http://www.eecs.harvard.edu/~lindig/software/lex-patch.html Yes. I just visited your homepage. I find it odd that it has not yet been adopted. Looking back at Ocaml mailing list archives, I think that this extension should perhaps be proposed again. Perhaps it was caused by my search paratemeters, but I found no responses from Ocaml team members to this proposal. Perhaps they missed it or just forgot about it. > > Can this technique be used for adding context to parsers generated > > using ocamlyacc, too? > > I'm not sure what you mean here. A Yacc parser works bottom up - do you > want to inject "context" into the tokens that are received from the > lexer? I want good error messages from the parser. I want the parser to have access to the line number information generated by the lexer. A simple way to let the parser have access to the information would be to pass it as a parameter to the parsing action code. So, is there a simple way to have a reentrant lexer and parser generated by ocamllex and ocamlyacc that would have line number information? I don't want to annotate all tokens by a line number. Furthermore, the Parsing module needs to be replaced at any rate because it has global state. The compiler we are implementing may be used by rather novice programmers (or actually non-programmers), so I'm willing to spend extra time polishing just the error messages, so that I don't have to spend the same amount of time (or possibly a lot more) explaining the errors to the users. > I agree that this alternative avoids the dependency of the type > definition on the grammar. But I am not sure that manually keeping the > type definition and the %token declarations in the parser in sync is > better than automatic recompiles or a little Make hack. The idea is that the .mly file would no longer have %token definitions. Instead it would have a definition such as follows: %token_type My_token_module.my_token_type This would cause ocamlyacc to read the my_token_type constructor names from the My_token_type module. Alternatively, the technique could be more low level. For instance: %token_type my_token_module.mli Which would simply read the first type definition from the my_token.mli file. ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr