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 0C04A7ED26 for ; Sun, 27 May 2012 20:18:09 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkCAEBvwk/RVdy2mWdsb2JhbABEgkWCca9bCCIBAQEBAQgLCwcUJ4IXAQEBAwESAg8EGQEbHAEBAwELBgULDQkWCwICCQMCAQIBEREBBQEcBg0BBwEBEAcHh1oBAwYFmXAJA4tbUIJwg20KGScNV4hxAQUMineELYESA5UXjhU9hBs X-IronPort-AV: E=Sophos;i="4.75,666,1330902000"; d="scan'208,217";a="160182061" Received: from mail-vc0-f182.google.com ([209.85.220.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 May 2012 20:18:08 +0200 Received: by vcbfy7 with SMTP id fy7so1957484vcb.27 for ; Sun, 27 May 2012 11:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=uUOeVPCWL5gJQUfJdaEmw8Bdu5NrUDNnQdSURmzoFc8=; b=Z0xPDgdjCPE5M7VMpcVf1bMCbAwXrouS7nkhxGTYg1LAbeKg9Bxcx69Qd8VD6hO7/a 4Es0MoOSXy9YdqvJ0qrE5fBJhTM3n3rwuF8uBxO/ixlLCaz2FpE0f4mT8WipxwyY5Huq OvgINXnKLBlIASdw7aXSCW1CD+YmdKLaIoa5Rk1W45+MNLTJYmZ0VilSr2/zdQZepWpD 94hzfMCO7XnEIAKkLVGxMeJ99F1op3AUzDX+7jIiIbf0GhCyfcBgbKP3kgXrPsIoMOKz GFYe48M3C22kIR6NKnDBI4IwHObV/ufRWIY2nCiVoZa/JKd926cDCXbOntS6KcX1Owv6 vogA== Received: by 10.220.91.74 with SMTP id l10mr6189106vcm.41.1338142686868; Sun, 27 May 2012 11:18:06 -0700 (PDT) Received: from bok053.wireless-pennnet.upenn.edu (bok053.wireless-pennnet.upenn.edu. [128.91.84.54]) by mx.google.com with ESMTPS id d11sm7698199vdt.14.2012.05.27.11.18.05 (version=SSLv3 cipher=OTHER); Sun, 27 May 2012 11:18:06 -0700 (PDT) Message-ID: <4FC26FDD.9010407@gmail.com> Date: Sun, 27 May 2012 14:18:05 -0400 From: Hongbo Zhang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= CC: caml-list@inria.fr References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040409060401080603090602" Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4 This is a multi-part message in MIME format. --------------040409060401080603090602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/27/12 2:04 PM, Daniel Bünzli wrote: > > Le dimanche, 27 mai 2012 à 18:53, Hongbo Zhang a écrit : > >> Well, I don't think it's good to downplay camlp4. The problem is we need >> more documentation and more tests. > > camlp4 is one of the (conceptually) ugliest component of the OCaml system. Pre-processors in general are a wrong solution to a real problem; meta-programming facilities should be part of the core language and play by its scoping rules, they should not be layered on top of it. Come on, Parsetree.structure->Parsetree.structure does not solve the scope rule problem. It's essentially a less powerful p4 tool and does not solve the problem at all. It just fragment the community again. > The aformentioned proposal is certainly not the best I'm hoping for (the definition and semantics of the attributes is defined by the build system). However it may be a step in the right direction. For one thing by preventing the extension of OCaml's concrete syntax and making attributes part of it, using them doesn't break other tools that act on OCaml sources files; the first one being your syntax highlighter. > > Best, > > Daniel > > --------------040409060401080603090602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 5/27/12 2:04 PM, Daniel Bünzli wrote: 

Le dimanche, 27 mai 2012 à 18:53, Hongbo Zhang a écrit :


Well, I don't think it's good to downplay camlp4. The problem is we need
more documentation and more tests.


camlp4 is one of the (conceptually) ugliest component of the OCaml system. Pre-processors in general are a wrong solution to a real problem; meta-programming facilities should be part of the core language and play by its scoping rules, they should not be layered on top of it.
Come on, Parsetree.structure -> Parsetree.structure does not solve the scope rule problem.
It's essentially a less powerful p4 tool and does not solve the problem at all. It just fragment the community again.

The aformentioned proposal is certainly not the best I'm hoping for (the definition and semantics of the attributes is defined by the build system). However it may be a step in the right direction. For one thing by preventing the extension of OCaml's concrete syntax and making attributes part of it, using them doesn't break other tools that act on OCaml sources files; the first one being your syntax highlighter.  

Best,

Daniel

--------------040409060401080603090602--