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 FAA31179; Sat, 1 May 2004 05:09:02 +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 FAA31227 for ; Sat, 1 May 2004 05:09:01 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4138wEV000550 for ; Sat, 1 May 2004 05:09:00 +0200 Received: from [192.168.1.200] (ppp116-155.lns1.syd2.internode.on.net [150.101.116.155]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i4138tk2092709 for ; Sat, 1 May 2004 12:38:57 +0930 (CST) Subject: [Caml-list] Ocamlyacc reentrancy From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list Content-Type: text/plain Message-Id: <1083380934.2581.321.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 May 2004 13:08:55 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 409314CA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; sourceforge:01 'the':99 threads:01 implemented:01 9660:01 glebe:01 reentrant:01 token:01 nsw:01 snail:02 parser:02 parser:02 checkout:02 stack:02 stack:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk As far as I can tell, Ocamlyacc parsers aren't reentrant: it uses static storage to hold the parser stack. There is even an argumentless clear function to empty 'the' stack after a parse is finished. It would be nice if we could get a re-entrant parser so recursive parsing could be done. This can be useful for processing '#include" files in C for example, if you want to handle that at the parse level instead of the token level. However, it may be possible to 'hack' something which allows this for sequential progamming (i.e. not with threads) by providing two functions: get_parser_state set_parser_state Does this make sense? Would it be useful to anyone else? Can it be implemented without too much fuss in lieu of a fully re-entrant parser? -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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