From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id A62E17ED26 for ; Mon, 28 May 2012 11:36:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgCALFGw09KN1ZKm2dsb2JhbABEgx2CFZ1lkjgBAQEBAQgJCwkUJ4IXAQEDAQEjSwsFCwsaAgkdAgJFAhAGGwqHawMGBQQHpWKIMQOJWIEkiV8bhBIyYAOWJoQtE40E X-IronPort-AV: E=Sophos;i="4.75,670,1330902000"; d="scan'208";a="160231631" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 May 2012 11:36:28 +0200 Received: from [192.168.0.100] (53-234.197-178.cust.bluewin.ch [178.197.234.53]) by smtp.webfaction.com (Postfix) with ESMTP id 7F8AA2103F41; Mon, 28 May 2012 04:36:07 -0500 (CDT) Date: Mon, 28 May 2012 11:35:36 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Wojciech Meyer Cc: Hongbo Zhang , caml-list@inria.fr Message-ID: <9B6D7FCED63545E2BB3F0DDD7B337AA1@erratique.ch> In-Reply-To: References: <4FC26FDD.9010407@gmail.com> <71FFF6A2CF1E4E6DA0FFF397B2084B89@erratique.ch> X-Mailer: sparrow 1.6 (build 1081.27) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4 Le lundi, 28 mai 2012 =C3=A0 00:43, Wojciech Meyer a =C3=A9crit : > Runtime meta-programming is a generalisation of static meta > programming. MetaOCaml has a nice set of abstraction to generate > typechecking code - yes - either at runtime or during compile time. You meant 'typechecked' (?). It's obviously a generalization but I didn't k= now there was support to use it at compile time.=20=20 =20=20 > The > problem is that it's purely for partial evaluation and not extending the > syntax.=20=20 Then it's perfect ! I think it's wrong to try to extend the language per se= . Most of the time, except for very particular things (e.g. introducing a m= onad notation), the dsl approach is perfectly sufficient. Don't think you a= bsolutely need to extend the OCaml grammar, embed your dsl directly into OC= aml, using OCaml language binders if you need variables.=20=20 Make libraries, not pet syntactic constructs.=20=20 Many things that can be done with camlp4, can be done with that approach. N= ot only is it very elegant, it's much easier to maintain w.r.t. the evoluti= on of the OCaml language itself. The techniques in these papers [1] should = be more known and used. > - It should not be external tool - like previously observed - it's > difficult to support for code highlighters or refactoring (tools in > general) - if it depends on a build step or command line options. If you extend the grammar itself, code highlighters or any tool expecting a= n OCaml expression is going to break whether the tool is external or not. B= ut for the rest of your comments I agree wholeheartedly (even though I'm no= t sure all that power is needed, but at least it would make the tool non-ug= ly to me). Best, Daniel [1]=20=20 http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.31.9782&rep=3Dre= p1&type=3Dpdf http://research.microsoft.com/apps/pubs/default.aspx?id=3D67334 =20=20 =20=20 > Therefore the main purpose of syntactical abstraction is missing > - but that's not a problem - MetaOCaml wasn't designed for it. >=20=20 > Things that I would like to see in future "incarnation" or integrating of > meta programming facilities to the language would be (beware that's my > blue dreams!): >=20=20 > - first of all non destructive updates to the grammar e.g: "let open > lang Sexp in ..." should open the Sexp syntax extension, install the > grammar, but when it goes out of scope it should vanish. Currently > Camlp4 can install, delete the rules after the functor is applied, and > no way of saying OK - let's go back. >=20=20 > - Composable - in particular one language should behave like a module, > or functor, should have an interface consisting of grammar rules, AST, > AST transforms etc. So one could parametrise one syntax extension > over another, and possibly reuse the language grammar or AST in > other. Currently Camlp4 syntax extension is just a single separate > module which when loaded possibly expects some existing grammar rules > to be in place and mutates them as it's needed. >=20=20 > - should be type safe and as mentioned before obey scoping rules. We > should be able to propagate type information even when the syntax > changes. This is difficult part - but I've seen it can be done with some > extra annotations - not talking about Camlp4 >=20=20 > - Recursive - it should be able to apply the grammar rules not only > once but expand until it reached the fixpoint. >=20=20 > - Reflective - it should be possible after each successful expansion have > the type information available for the next expansion. >=20=20 > - Grammar itself should be lexer-less - memoizing PEG with left > recursion - it's hurdle to define new grammar in terms of old lexer, > or having a stateful lexer that depends on context. >=20=20 > - It should not be external tool - like previously observed - it's > difficult to support for code highlighters or refactoring (tools in > general) - if it depends on a build step or command line options. >=20=20 > That's said I find Camlp4 extremely useful for code generation purposes > - when I need to generate some ML code through quotations. Also, some > very important projects depend on Camlp4 (or Camlp5) like Coq. I don't > see that ML can live without some meta programming facilities out of the > box. >=20=20 > --=20=20 > Wojciech Meyer > http://danmey.org >=20=20 > --=20=20 > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs