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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 01E15BC57 for ; Fri, 25 Jun 2010 11:35:50 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBANgVJEzRVdY2mGdsb2JhbACfOQgVAQEBAQEICQwHESKwO4IJhWguiFMBAQMFhRwEhAGLCA X-IronPort-AV: E=Sophos;i="4.53,480,1272837600"; d="scan'208";a="62117229" Received: from mail-bw0-f54.google.com ([209.85.214.54]) by mail1-smtp-roc.national.inria.fr with ESMTP; 25 Jun 2010 11:35:49 +0200 Received: by bwz17 with SMTP id 17so1238820bwz.27 for ; Fri, 25 Jun 2010 02:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=ErqiKwH2wH7PKX8I5pC1FauWA9qJ4X4aoH9PGL5VYzk=; b=u6Ets+COAd2P7x4rcmNBHRhrEQ8Wd/hwSiaFlEoxDuUSGgQAuWpFplsRyvwn2a93Aw zXCVSrwIE1sKoR2rJ/ybSIGrxj4sgOZ32nCgFaKi3iq7BD2SVX87JS2o6bnERiwjai0S OMf/tLfkCkU+zKN1MvF4ZnLtFjaY3xFjOj3CE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=pHgl6pzhzaU9NLdKYKpqZ8nf8b9LeNNUrr5zFetYWDY7T2B3UhdjI4z0IsFizzd2tX xXxeTr8Zl1xzFR0QGDlwWKmPnZ/EjiYGfZJ0okovDnRPnxR8rmYAEUz0wx9kUMZWmuQY HqVRrXNNtN8Up7FQJcIhPSp9P96k9khnfHnbo= Received: by 10.204.73.193 with SMTP id r1mr305689bkj.111.1277458549229; Fri, 25 Jun 2010 02:35:49 -0700 (PDT) MIME-Version: 1.0 Sender: gabriel.scherer@gmail.com Received: by 10.204.68.148 with HTTP; Fri, 25 Jun 2010 02:35:29 -0700 (PDT) In-Reply-To: References: <4C232778.2020605@imag.fr> <4C2399B0.4060503@ens-lyon.org> <20100624205906.48451eor602oaf3u@webmail.imag.fr> <20100624224944.91886zxkgzxq78iw@webmail.imag.fr> <20100625000544.142418fa5cp6ye9k@webmail.imag.fr> <20100625082404.19864c8w6r8962kk@webmail.imag.fr> From: bluestorm Date: Fri, 25 Jun 2010 11:35:29 +0200 X-Google-Sender-Auth: toEtDuC8zyDVKv7iLM-N6EZYLoE Message-ID: Subject: Re: [Caml-list] OCaml 3.12.0+beta1 To: David Allsopp Cc: Florent Ouchet , caml users Content-Type: multipart/alternative; boundary=0016e6dd8f610ac7c10489d77f77 X-Spam: no; 0.00; ocaml:01 ocaml:01 compiler:01 camlp:01 camlp:01 work-around:01 compiler:01 damien:01 bug:01 messes:01 ocamldoc:01 translated:01 ocamldoc:01 annotations:01 syntax:01 --0016e6dd8f610ac7c10489d77f77 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 25, 2010 at 10:48 AM, David Allsopp wrote: > > If *your* code has to be *backwards*-compatible with the OCaml 3.11.x > compiler then you shouldn't be using that shorthand at all. [..] Any > features in 3.12 shouldn't be being used at all *if* 3.11 compatibility is > your goal. The problem is that camlp4 doesn't distinguish at present between "a; " and "a = a;" as label patterns : the former is desugared into the latter while parsing. With the current implementation, both will be pretty-printed as "a = a;". It may happen however than the implementation change and both be printed as "a;". In that case, my implementation would break. That's what I meant. In the best of all worlds (user-wise), Camlp4 would track that information and always output "a;" when there was "a;", and "a = a;" otherwise. I'm not sure it's worth complicating the Camlp4 AST again for such a feature. It is possible to work-around this issue by using a slightly more subtle pattern : my filter could for example translate "a = a" in "a = (_ as a)", wich is equivalent and surely wouldn't be resugared. > I'm sure we all agree that any well-written piece of code should never emit > compiler warnings I don't agree. Warnings are there for things that could be errors, but are not necessarily one. In some case you'll want to break the rules. You may use build options to disable the specific warning in the specific file, but that's not necessarily a good idea. I'm happy with some warning remaining if they're justified. This discussion is reminiscent of on the warn-error problem we were recently warned (!) about by Damien (do not use warn-error for released code !) : http://caml.inria.fr/pub/ml-archives/caml-list/2009/11/91883440c8a0481a4233758946e5c3bf.fr.html > As an aside, while it seems fair enough that a pre-processor such as camlp4 > may mess up *comments* it seems to me a bug that it messes up ocamldoc > *instructions* (which are reasonably viewable as a functional part of your > code). But is that a well-rehearsed argument about a really unfixable > problem? > In that case, it isn't really a problem. There could be an issue if an user want to build documentation for a 3.12 code translated into a 3.11 code by a camlp4 filter. Why not simply use ocamldoc-3.12 to generate the documentation instead ? For the generate case, well, it is a problem. OCaml doc instructions are comments (if we're both talking about the (** .. *) thing), and comments and whitespace are not handled well by syntaxic AST for language where they don't matters. Ocamldoc use a comment position hack to associate comments to the caml AST, and while it's probably a necessary hack, I'm not sure it's fair to blame camlp4 for breaking it. If you really want language-integrated documentation, the Right Thing To Do is to keep places for documentation/annotations directly in the language syntax (and AST). This is what Python has done with the "docstring" wich has a dedicated place in declarations. There is no such thing in Ocaml syntax, so we have to use workarounds that work reasonably well, but not always. --0016e6dd8f610ac7c10489d77f77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 25, 2010 at 10:48 AM, David = Allsopp <dra= -news@metastack.com> wrote:

If *your* code has to be *backwards*-compatible= with the OCaml 3.11.x compiler then you shouldn't be using that shorth= and at all. [..] Any features in 3.12 shouldn't be being used at all *i= f* 3.11 compatibility is your goal.

The problem is that camlp4 doesn't distinguish at p= resent between "a; " and "a =3D a;" as label patterns := the former is desugared into the latter while parsing. With the current im= plementation, both will be pretty-printed as "a =3D a;". It may h= appen however than the implementation change and both be printed as "a= ;". In that case, my implementation would break. That's what I mea= nt.

In the best of all worlds (user-wise), Camlp4 would tra= ck that information and always output "a;" when there was "a= ;", and "a =3D a;" otherwise. I'm not sure it's wort= h complicating the Camlp4 AST again for such a feature.

It is possible to work-around this issue by using a sli= ghtly more subtle pattern : my filter could for example translate "a = =3D a" in "a =3D (_ as a)", wich is equivalent and surely wo= uldn't be resugared.

=A0
I'm sure we all agree that any well-written piece of code should never = emit compiler warnings

I don't agree. W= arnings are there for things that could be errors, but are not necessarily = one. In some case you'll want to break the rules. You may use build opt= ions to disable the specific warning in the specific file, but that's n= ot necessarily a good idea. I'm happy with some warning remaining if th= ey're justified.

This discussion is reminiscent of on the warn-error pro= blem we were recently warned (!) about by Damien (do not use warn-error for= released code !) :=A0http://caml.inria.fr= /pub/ml-archives/caml-list/2009/11/91883440c8a0481a4233758946e5c3bf.fr.html=

=A0
As an aside, while it seems fair enough that a pre-processor such as camlp4= may mess up *comments* it seems to me a bug that it messes up ocamldoc *in= structions* (which are reasonably viewable as a functional part of your cod= e). But is that a well-rehearsed argument about a really unfixable problem?=

In that case, it isn't really a proble= m. There could be an issue if an user want to build documentation for a 3.1= 2 code translated into a 3.11 code by a camlp4 filter. Why not simply use o= camldoc-3.12 to generate the documentation instead ?


For the generate case, well, it is a pro= blem. OCaml doc instructions are comments (if we're both talking about = the (** .. *) thing), and comments and whitespace are not handled well by s= yntaxic AST for language where they don't matters.
Ocamldoc use a comment position hack to associate comments to the caml= AST, and while it's probably a necessary hack, I'm not sure it'= ;s fair to blame camlp4 for breaking it.


If you really want language-integrated documentation, the Right Thing = To Do is to keep places for documentation/annotations directly in the langu= age syntax (and AST). This is what Python has done with the "docstring= " wich has a dedicated place in declarations.
There is no such thing in Ocaml syntax, so we have to use workarounds = that work reasonably well, but not always.
--0016e6dd8f610ac7c10489d77f77--