[wg-camlp4] [Caml-devel] Built-in attributes

[Alain Frisch]

On 04/14/2014 11:58 PM, Gabriel Scherer wrote:
> - I see the point of namespacing to avoid conflicts but I suspect
> conciseness is also important here, if we want to use warning-tweaking
> directives in a fine-grained enough way

I don't particularly want to encourage that.  The standard use for 
[ocaml.warning] I have in mind is to control warnings for an entire 
compilation unit (thus simplifying the build system and making the unit 
more self-contained), maybe for a "section" of it (hence the warning on 
expressions, to allow begin[@ocaml.warning "..."] .... end), especially 
during development.  It would be a mess if people start to decorate 
their code with long-lasting warning-tweaking directives all over the 
place, in my opinion.  (Especially from a readability point of view: 
numbered warnings are quite unfriendly.)

> - I suspect that the idea of warning over unknown ocaml.foo attributes
> is papering over the real difficulty, which is the fact that it's very
> easy to make a mistake if warnings are ignored by default. While giving
> more structure to an "ocaml" namespace solves the particular problem
> Damien had with deprecated, chances are users will still have their
> problems with the warnings they define on their own (or what about
> [@@OCaml.warning]). We may want to think harder about resilience to user
> mistakes to aim for a less ad-hoc solution.

A tool which checks for correct use of warnings could be useful, and not 
too difficult if one restrict to a "white-list" of known attributes 
(maybe some information about where they can be used, and potentially 
with some "typing" information).  Each tool operating on attributes (ppx 
or others) could come with a description of what it understands, to be 
processed by this checking tool.

That said, I wouldn't be surprised if code made available publicly 
contains attributes to be interpreted by tools which are not necessarily 
available where that code is compiled.  For instance, a company could 
publish code containing some internal "code review markers" (implemented 
as attributes).


Alain