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 F3D0EBB83 for ; Thu, 20 Jul 2006 03:11:45 +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 k6K1BjAr012507 for ; Thu, 20 Jul 2006 03:11:45 +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 DAA25043 for ; Thu, 20 Jul 2006 03:11:44 +0200 (MET DST) Received: from exchfe2.cs.cornell.edu (exchfenlb-2.cs.cornell.edu [128.84.97.34]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k6K1BiBV026242 for ; Thu, 20 Jul 2006 03:11:44 +0200 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 21:11:43 -0400 Received: from [192.168.1.100] ([24.59.194.44]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 21:11:43 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: quoted-printable Message-Id: <51E3580C-02A1-4344-A5AA-862B580015F1@cs.cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: caml-list@inria.fr From: Eric Breck Subject: Re: On language extensions (was Re: [Caml-list] global record) Date: Wed, 19 Jul 2006 21:12:39 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Jul 2006 01:11:43.0296 (UTC) FILETIME=[767E1C00:01C6AB99] X-Miltered: at concorde with ID 44BED851.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44BED850.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 syntax:01 semantics:01 syntax:01 author's:01 trade-off:01 camlp:01 camlp:01 coq:01 ocaml's:01 locality:01 optionally:01 locality:01 api: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 > From: Daniel_B=FCnzli > Subject: On language extensions (was Re: [Caml-list] global record) > > Contrary to lisp's macros, each syntax extension is syntactically a > new language. Hence not only do we need to learn a new semantics but > also a new syntax. If I have to read someone else's code I want to > read caml code and not caml code augmented with the author's > syntactic obsessions. > > In code readability, there is a trade-off between succinctness and > syntactic regularity. Camlp4 extensions increase the former but > decrease the latter. For me camlp4's usage should be limited to real > domain specific languages (e.g. like coq does) and research, it > should not be used to increase ocaml's succinctness. Succinctness is not precisely what I was after so much as locality - =20 in this case, having each option declared in a single location - as =20 opposed to the type definition in one place, the default value in =20 another, the Arg.spec in another, code to print the chosen value of =20 each option in another, and, optionally, the de-ref-ication in =20 another. Such locality is a basic principle of software engineering, =20= and in this case I don't really know how to achieve it with only a =20 library (and not a syntax extension). I'm not advocating extending the language willy-nilly, but I feel =20 that any new library already requires some amount of learning to use =20 its particular API, and if a small, local extension to the language =20 vastly shrinks (and localizes) code required to interface to the =20 library, it seems reasonable to me (IMHO). To put it another way, I do not agree with the adage that "syntactic =20 sugar causes cancer of the semicolon." :) As far as readability, I tried to choose syntax that would make clear =20= to a casual reader what was going on, but clearly I'm blinded by =20 having stared at this for awhile now. As Nicolas Pouillard points =20 out, you can always unsugar the code. Anyway, I've been using variants of this library for half a year or =20 so, and I've found it very convenient, so I thought I would offer it =20 to others. > This may be seen as a matter of personal taste: it is true that I > lean towards syntactic regularity, i.e. less syntactic constructs. > However there is another argument against using extensions: code > maintenance. 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 doesn't =20 try to make large-scale changes to the grammar. > 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. A solution along =20 those lines to my problem (locality of command-line arguments) would =20 be something like this: specify the options in some file, write some =20 piece of code to process this and produce an ocaml file, which is =20 then compiled and linked with the main program. I actually =20 originally did something along these lines, but then decided that =20 since this approach also requires defining and processing a new =20 syntax (of the option file), I would use camlp4 and integrate that =20 syntax into my main program. That is, camlp4 *is* meta-programming, =20 it's just that it (a) integrates the DSL into the main program, and =20 (b) hides the intermediate file. But perhaps I'm misunderstanding your point - if you could clarify =20 what you mean, I'd like to know what alternate approaches are. Finally, I have the sense (perhaps I'm completely wrong) that the =20 post I'm responding to was motivated in part by a thought that =20 command-line option parsing is somehow not worthy of a domain-=20 specific language / syntax extension. I suppose it is something of a =20= "syntactic obsession" with me to find a clear and concise way of =20 specifying such options, since I write mostly small, command-line =20 programs to which I want to be able to quickly add variant =20 functionality. Clearly, the benefit to any particular program is =20 small - when you write enough of them, though, the lifetime savings =20 in tearing-my-hair-out is, I think, a win. best, -E r i c (PS: sorry if this doesn't get threaded appropriately, I read the =20 digest of the list).