caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Allsopp <dra-news@metastack.com>
To: bluestorm <bluestorm.dylc@gmail.com>,
	Florent Ouchet <florent.ouchet@imag.fr>
Cc: caml users <caml-list@inria.fr>
Subject: RE: [Caml-list] OCaml 3.12.0+beta1
Date: Fri, 25 Jun 2010 08:48:31 +0000	[thread overview]
Message-ID: <E51C5B015DBD1348A1D85763337FB6D9065B96@Remus.metastack.local> (raw)
In-Reply-To: <AANLkTilObXVbEfPuBWf-fDprgu0oi16xMve7inu2FDIb@mail.gmail.com>

bluestorm wrote:
> Here is a small Camlp4 filter removing exhaustive patterns. It obviously depends on 3.12.
>
<snip>
> 
>
> Notes :
> - that the OCaml printer expand sugared { a; b } patters into { a = a; b = b } is necessary 
> for printing backward-compatible code; I'm not sure it's a good idea to rely on this.

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 - the point with the {; _} syntax is that it's necessary to suppress a warning in OCaml 3.12 which isn't present in 3.11 (in other words, that syntax has to be used in 3.12 as I'm sure we all agree that any well-written piece of code should never emit compiler warnings). Any features in 3.12 shouldn't be being used at all *if* 3.11 compatibility is your goal.

> - as with every camlp4 filters, the code is parsed then pretty-printed; do not expect indentation
>  to stay as is. Comment placement is also going to do weird things (know and nearly-unfixable camlp4 defect)

Seems fine.

>  : ocamldoc may not work properly on the output code.

Sounds like a showstopper for most packages as that would break doc/docs Makefile targets (shame, because a camlp4 script seems the obvious way to do it). Presumably any package that's going to be written for 3.12 but aim to compile on 3.11.x is going to have to .311.ml files (or some such scheme) generated for the sources tarball and then have those selected by a configure script when it detects OCaml 3.11.x or earlier (similar scheme to supporting 3.09- camlp4 and 3.10+ camlp4). If camlp4 sadly can't do it reliably, how about combining the sed suggestion you made:

sed -e "s/; *_ *}/}/g"

with a test compilation in OCaml 3.11 to pick up any instances where line-breaking has been a problem (in other words, change your coding conventions and use the compiler to check that they've been adhered to)? It's not a particularly hard sed[*] script to read a few lines at a time and change the regexp to "s/;[ \t\n]*_[ \t\n]*}/}/g" to handle different line breaking conventions as well (and you could insert an additional regexp to handle non-nested comments in that gap as well). That would have the benefit of not messing up ocamldoc comments.

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?


David


[*] or substitute your favourite text processor here!


  reply	other threads:[~2010-06-25  8:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 13:07 Damien Doligez
2010-06-16 16:28 ` [Caml-list] " Yoann Padioleau
2010-06-16 18:40   ` Martin Jambon
2010-06-16 20:52 ` Török Edwin
2010-06-17 13:35   ` xclerc
2010-06-18 14:56     ` xclerc
2010-06-19  5:51 ` Stéphane Glondu
2010-06-24  9:38 ` Florent Ouchet
2010-06-24 17:45   ` Martin Jambon
2010-06-24 18:59     ` Florent.Ouchet
2010-06-24 19:29       ` Dmitry Bely
2010-06-24 19:31       ` Mathias Kende
2010-06-24 19:39       ` Till Varoquaux
2010-06-24 20:49         ` Florent Ouchet
2010-06-24 20:57           ` Hezekiah M. Carty
2010-06-24 22:05             ` Florent Ouchet
2010-06-25  5:54               ` bluestorm
2010-06-25  6:24                 ` Florent Ouchet
2010-06-25  8:17                   ` bluestorm
2010-06-25  8:48                     ` David Allsopp [this message]
2010-06-25  9:35                       ` bluestorm
2010-06-25  7:29 ` bluestorm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E51C5B015DBD1348A1D85763337FB6D9065B96@Remus.metastack.local \
    --to=dra-news@metastack.com \
    --cc=bluestorm.dylc@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=florent.ouchet@imag.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).