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 B8B98BB83 for ; Thu, 20 Jul 2006 14:42:19 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k6KCgI5A012326 for ; Thu, 20 Jul 2006 14:42:19 +0200 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 OAA03528 for ; Thu, 20 Jul 2006 14:42:18 +0200 (MET DST) Received: from smtp2.epfl.ch (smtp2.epfl.ch [128.178.50.133]) by nez-perce.inria.fr (8.13.6/8.13.6) with SMTP id k6KCgHfu004773 for ; Thu, 20 Jul 2006 14:42:18 +0200 Received: (qmail 12778 invoked by uid 107); 20 Jul 2006 12:42:14 -0000 Received: from mailav3.epfl.ch (128.178.2.11) by smtp2.epfl.ch with SMTP; 20 Jul 2006 12:42:14 -0000 Received: from (128.178.50.19) by MAILAV3.epfl.ch via smtp id 6b13_2b731592_17ed_11db_9756_0014221528b0; Thu, 20 Jul 2006 14:42:13 +0200 Received: from lampmac3.epfl.ch (128.178.154.94) by smtp0.epfl.ch (AngelmatoPhylax SMTP proxy); Thu, 20 Jul 2006 14:42:14 +0200 In-Reply-To: <51E3580C-02A1-4344-A5AA-862B580015F1@cs.cornell.edu> References: <51E3580C-02A1-4344-A5AA-862B580015F1@cs.cornell.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <60FD7628-7F4E-4765-88AD-B3AB7DA987D0@epfl.ch> Cc: caml-list@inria.fr Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= Subject: Re: On language extensions (was Re: [Caml-list] global record) Date: Thu, 20 Jul 2006 14:42:13 +0200 To: Eric Breck X-Mailer: Apple Mail (2.752.2) X-Miltered: at concorde with ID 44BF7A2B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44BF7A29.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 epfl:01 locality:01 optionally:01 locality:01 syntax:01 typechecker:01 syntax:01 api:01 vastly:01 api:01 semantics:01 grammar:01 ocaml: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.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Le 20 juil. 06 =E0 03:12, Eric Breck a =E9crit : > Succinctness is not precisely what I was after so much as locality =20 > - in this case, having each option declared in a single location - =20 > as opposed to the type definition in one place, the default value =20 > in another, the Arg.spec in another, code to print the chosen value =20= > of each option in another, and, optionally, the de-ref-ication in =20 > another. Such locality is a basic principle of software =20 > engineering, and in this case I don't really know how to achieve it =20= > with only a library (and not a syntax extension). The typechecker (indirectly) gives you that locality, it tells you =20 exactly where changes are needed and frankly all this is in the same =20 module, maybe even on the same page. If I have to maintain your code =20 I'll understand quicker hand made code than your syntax extension =20 (especially since I already know how the Arg module works). > I'm not advocating extending the language willy-nilly, but I feel =20 > that any new library already requires some amount of learning to =20 > use its particular API, and if a small, local extension to the =20 > language vastly shrinks (and localizes) code required to interface =20 > to the library, it seems reasonable to me (IMHO). Api is not new syntax. As a said before when you learn an api you =20 only need to understand new semantics. > As far as readability, I tried to choose syntax that would make =20 > clear to a casual reader what was going on, but clearly I'm blinded =20= > by having stared at this for awhile now. As Nicolas Pouillard =20 > points out, you can always unsugar the code. For small examples this can be a solution. But I usually prefer not =20 to read machine generated code. Most programmer (I hope) reread their =20= code and try to make it readable and elegant, a machine won't. >> You have no guarantee that (1) an extension will not be >> broken by the next version of the language and (2) that the author >> will continue to maintain it. > > I'm not sure why either 1 or 2 is more true for a syntax extension =20 > than for an arbitrary library, assuming the syntax extension =20 > doesn't try to make large-scale changes to the grammar. I agree on this point for 2 but not on 1. Incompatible language =20 changes are rare (inexistant ?) with ocaml. >> P.S. Even for domain specific languages many things can be done in >> pure ocaml by embedding the dsl in ocaml using meta-programming >> techniques. > > I'm not sure what you mean here. I understand meta-programming to =20 > mean (roughly) generating code programatically. I was not specifically talking about your problem here, though I =20 could maybe be applied. It was more on using caml to write code that =20 should be written in another language (e.g. regexps, sql, etc.), =20 instead of writing a horrible language extension that will allow you =20 to mix both languages or use caml strings, see [1] for more information. I'm sorry to say that but I regard (maybe out of ignorance) camlp4 as =20= very low level and brittle tool (not to say hack). An obvious proof =20 of this to me is the composition problem which is according to =20 previous messages is not solved by camlp4. Best, Daniel [1] @article{967844, author =3D {Conal Elliott and Sigbj\&\#248;rn Finne and Oege De Moor}, title =3D {Compiling embedded languages}, journal =3D {J. Funct. Program.}, volume =3D {13}, number =3D {3}, year =3D {2003}, issn =3D {0956-7968}, pages =3D {455--481}, doi =3D {http://dx.doi.org/10.1017/S0956796802004574}, publisher =3D {Cambridge University Press}, address =3D {New York, NY, USA}, }=