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

[Dario Teixeira]

Hi,

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

Gabriel has a point here.  As I see it, there are three broad approaches to namespacing:

  1) Namespace nothing.  Use social norms to avoid name clashes between different projects.

  2) Namespace everything, including compiler extensions.  Compiler can even enforce this
     usage by requiring extension points to be of the form "ns.name".

  3) No namespacing for generic and builtin attributes, such as "default", "warning",
     or "author", but socially-enforced namespacing for extension-specific attributes.

Here's my problem with solution 2: how do we deal with generic attributes that could be
used by more than one extension?  (For instance, attribute "default" used by Sexplib
or Bin-prot, or documentation attributes such as "author" used by tools such as Ocamldoc).
This is why I'm leaning more towards solution 3.  This approach would require a centrally
maintained list of non-namespaced attributes (a disadvantage, I admit), but this list
would be small and fairly static (we could require broad community approval before
adding another attribute).  All other attributes would be namespaced, though I imagine
that the namespacing could itself be a social convention (eg. "proj.attr") instead
of being enforced by the compiler.

As for the other problem Gabriel raised -- typos going unnoticed -- I reckon tooling
outside the compiler could be of help.  A tool that went through the code base and
checked each usage of an extension point against a project whitelist would catch typos,
for instance.

Best regards,
Dario Teixeira