From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 6AFD3BB84 for ; Tue, 16 May 2006 22:16:40 +0200 (CEST) Received: from dell.nogin.org (charter-242-015.caltech.edu [131.215.242.15]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4GKGcd8018158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 May 2006 22:16:39 +0200 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dell.nogin.org (Postfix) with ESMTP id 7606B39A32F; Tue, 16 May 2006 13:16:34 -0700 (PDT) Message-ID: <446A331F.4000205@cs.caltech.edu> Date: Tue, 16 May 2006 13:16:31 -0700 From: Aleksey Nogin Reply-To: MetaPRL Developers , OCaml Mailing List Organization: California Institute of Technology, Computer Science Department User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Pouillard Cc: OCaml Mailing List , MetaPRL Developers Subject: Re: [Caml-list] [Camlp4] Beta-release References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 446A3326.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; camlp:01 camlp:01 ocaml:01 grammar:01 parsing:01 parsers:01 pointer:01 delayed:01 parsing:01 grammars:01 ocaml:01 grammar:01 viewcvs:01 functor:01 functor:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 I have a question/feature request. For our camlp4 usage (in MetaPRL theorem prover - http://metaprl.org/ ), we need to: - extend the OCaml grammar - refer to a "state" when parsing the extensions. Currently we have to put the state in a global ref (yuck!), which causes all kinds of difficulties. Is this something that can be done better in your reimplementation? Can something like this be added to your reimplementation? Basically, I would really like to see camlp4 help with the following: 1) Defining parsers that depend on a shared state that is passed around. Currently one can either a) use a global pointer ref, or b) manually define the productions of "state -> ..." type and manually pass the state around. (a) is obviously bad, but even (b) is not only a lot of extra typing, but also means that the execution of productions will be delayed until the whole thing is parsed, which would mean that when something goes wrong, you would often get a campl4 parsing error instead of a (usually more meaningful) error generated by the production code. 2) Allow passing shared state even for grammars that extend things like OCaml grammar. 3) (completely unrelated) I wish there was a way to tell camlp4 to detect and report conflicts! P.S. The bulk of our camlp4 code is in http://svn.metaprl.org/viewcvs/mojave/metaprl/filter/filter/term_grammar.ml (the shared state is hidden in a way here - the grammar is created in a functor where the input module provides functions like mk_opname; when the functor will be instantiated, the functions would be made dependent on a number of global refs) and in http://svn.metaprl.org/viewcvs/mojave/metaprl/filter/filter/filter_parse.ml (here we actually extend the OCaml grammar, using some of the stuff from term_grammar.ml in that extension). If you are interested in downloading MetaPRL sources to look at this stuff in more detail, please see the download instructions at http://metaprl.org/install.html -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal) Office: Moore 04, tel: (626) 395-2200