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 360757ED26 for ; Wed, 30 May 2012 16:17:41 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIBAI0rxk/RVdQ2kGdsb2JhbABEgkWIY6hdCCIBAQEBCQkNBxQEI4IXAQEBAwESAiwBGxwBAQMBCwYFBAcNCRYPCQMCAQIBEREBBQEcBg0BBwEBHodaAQMGBZpSCQOMK4JwhQcKGScNV4hxAQUMkDsDlRiOFj6EGw X-IronPort-AV: E=Sophos;i="4.75,685,1330902000"; d="scan'208,217";a="160591230" Received: from mail-vb0-f54.google.com ([209.85.212.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 May 2012 16:17:07 +0200 Received: by vbmv11 with SMTP id v11so5425436vbm.27 for ; Wed, 30 May 2012 07:16:45 -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=DK6uRWvm7KivOvA0X8xMIv/sC+ug82EMqK7EcoKYY8Y=; b=xrbjIHxfxjcijRCBD0mWu2FBHn1PXfEEmGsBbS+3x/EcIeC0XaaoKuy+VpIYifP4PZ XDz+JpGWAy339dve4C+SWr/sB9h7HZrHRot6G4u0d0wD/7M3YLnhvagqq48sQirDAw3r TIcfjklk5nEwA+R/Euz49tDoKtGVoc0AQMeQEKk6rZwfoGegfZKcYZVXzqJD+gFpaBea RpMw02PA47hO9bJ8hgW0fFmB3qHi7ufnlrrOQft1djy0QeL8QC7OAm8GBL0GKzbTyx31 nC8NSJ0neeUbg3rf4c4K6JsgA0wKfd98I4hGD3h7KmY68JXGVzNgDpT2oQksz2hIKKdN 7Iqw== Received: by 10.52.100.36 with SMTP id ev4mr14259173vdb.43.1338387405255; Wed, 30 May 2012 07:16:45 -0700 (PDT) Received: from vpl317.wlan.library.upenn.edu (vpl317.wlan.library.upenn.edu. [130.91.141.62]) by mx.google.com with ESMTPS id o15sm29836323vdi.15.2012.05.30.07.16.44 (version=SSLv3 cipher=OTHER); Wed, 30 May 2012 07:16:44 -0700 (PDT) Message-ID: <4FC62BCA.4030108@gmail.com> Date: Wed, 30 May 2012 10:16:42 -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: Dan Bensen CC: Alain Frisch , caml-list@inria.fr References: <4FC61595.6070009@frisch.fr> <1338385022.96299.YahooMailRC@web180009.mail.gq1.yahoo.com> In-Reply-To: <1338385022.96299.YahooMailRC@web180009.mail.gq1.yahoo.com> Content-Type: multipart/alternative; boundary="------------060604090108090202030101" Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4 This is a multi-part message in MIME format. --------------060604090108090202030101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/30/12 9:37 AM, Dan Bensen wrote: > > > > I don't think it's good to downplay camlp4. > > > we need more documentation and more tests. > > > (The new) Camlp4 has been here for several years. > > Documentation and tests are still lagging behind. > > Is it possible for Inria or someone else to provide > funding for that? I would like to help out starting > sometime in the summer. > Actually I am writing a book about the internal part of camlp4 (100~200 pages), but nobody seems to care about it. > > the most common uses of camlp4 might be based on a much > > simpler approach ... Coq is one of the few examples of > > a big project that relies on other aspects of camlp4 > > Why not focus on optimizing new lightweight tools for > small problems and keep camlp4 for big ones? It wouldn't > be so bad if it were documented better. I think it's a good idea to build simple tools on top of existing more powerful tools instead of dropping the latter. --------------060604090108090202030101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/30/12 9:37 AM, Dan Bensen wrote:

> > I don't think it's good to downplay camlp4.
> > we need more documentation and more tests.

> (The new) Camlp4 has been here for several years.
> Documentation and tests are still lagging behind.

Is it possible for Inria or someone else to provide
funding for that? I would like to help out starting
sometime in the summer.

Actually I am writing a book about the internal part of camlp4 (100~200 pages),
but nobody seems to care about it.

> the most common uses of camlp4 might be based on a much
> simpler approach ... Coq is one of the few examples of
> a big project that relies on other aspects of camlp4

Why not focus on optimizing new lightweight tools for
small problems and keep camlp4 for big ones? It wouldn't
be so bad if it were documented better.

I think it's a good idea to build simple tools on top of existing more powerful tools instead of dropping the latter.

--------------060604090108090202030101--