Re: [Caml-list] OCaml 3.12.0+beta1

[bluestorm <bluestorm.dylc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3141 bytes --]

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 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.

[-- Attachment #2: Type: text/html, Size: 4355 bytes --]