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.