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!
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
