From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBAKtigu026158 for ; Sat, 10 Dec 2011 21:55:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIzG407VuiYS/2dsb2JhbABDhDdQpXeBBYFyAQEFDBdRBRAJAhoCJgICLCsGJ4d2BqM1kQ4UgSCJI4EWBKcZ X-IronPort-AV: E=Sophos;i="4.71,332,1320620400"; d="scan'208";a="134854784" Received: from solaria.dimino.org ([213.186.38.18]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 10 Dec 2011 21:55:39 +0100 Received: from aurora (localhost.localdomain [127.0.0.1]) by solaria.dimino.org (Postfix) with ESMTP id E1A9980088; Sat, 10 Dec 2011 21:55:38 +0100 (CET) Received: by aurora (Postfix, from userid 1000) id 450CD40440; Sat, 10 Dec 2011 21:55:44 +0100 (CET) Message-ID: <1323550544.32136.19.camel@aurora> From: =?ISO-8859-1?Q?J=E9r=E9mie?= Dimino To: Wojciech Meyer Cc: Xavier Leroy , caml-list@inria.fr Date: Sat, 10 Dec 2011 21:55:44 +0100 In-Reply-To: References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <1323541702.32136.8.camel@aurora> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBAKtigu026158 Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) Le samedi 10 décembre 2011 à 19:10 +0000, Wojciech Meyer a écrit : > I'm asking, because certainly it would be a very wanted feature. I can > see two major limitations of the current Camlp4/p5 system: > > - no way of recursively expand syntax, generate some code and then > re-generate again using same syntax (staging, it's partially there as > you can compose syntax extensions, but there is no way to keep > expanding until fixpoint) > > - no way of making an action based on inferred type during previous stage > of macro expansions. This is biggie. It needs either using `ocaml -i' hack > or kind of type reflection support in the compiler. > > Also, a packrat lexless parsers with a way to compose them would be a > huge thing too. > > I'm aware that these are huge changes to Camlp4, but it would make > meta programming more powerful and push Camlp4 to the next level. Sure. But it seems that the next version of OCaml will have runtime types, see http://www.lexifi.com/blog/runtime-types , so maybe it is not needed to add this to camlp4. Also they are problems that i don't know how to solve with the camlp4 approach. For example consider: let x = 1 type int = A let y = A The typer knows that x has the type (int, 1) and y has the type (int, 42). But what you send to ocaml is a parse tree, and you cannot make this difference in the parse tree. Cheers, -- Jérémie