[wg-camlp4] A new branch to experiment with extension points

[Alain Frisch]

On 03/01/2013 02:40 PM, Gabriel Scherer wrote:
> I'm not fond of having "with" as a special case. If you don't support
> the type-conv or deriving syntax as is, could we take this as an
> opportunity to go back to an uniform syntax? Type declaration could be
> handled like any structure item.

Cf my previous email:

> There will be a need for attributes on individual type declarations (not only structure items, since a set of mutually recursive declarations in a single structure item), and "with" seems quite good.

An alternative solution would be to consider each declared type as its 
own structure item, so that we wouldn't need an extra notation for 
attributes attached to them.  This changes the current definition of the 
Parsetree.  Do you think it would be a good idea?

> Don't we want to have attributes on signature items as well?

Of course we do.  Also on patterns, class expressions, module 
expressions, module types, etc.

> Finally, I bet the non-terminal ".." will get little love, but I'm
> sure you considered other option (for example just ;;(:foo), but that
> doesn't work in the toplevel and we really want ";;" to help *avoid*
> precedence issues) and trust that this is one of the less ugly ones.

Even without considering technical issues with it, ;;(:foo) does not 
seem so good, because ;; looks like a strong end delimiter for the 
reader and it is weird to have something after it related to what's 
before.  (In the same way that it is weird to have a parenthesized 
sentence after a full dot if if related to the previous sentence :-))

> Is that proposal sufficient to do ocamldoc with structured attributes
> rather than comments? It looks like it is. Can an annotation node, by
> itself, stand as a structure item (I'm thinking section comments)?

An extension nodes stands as a structure item:

..(&foo)

but the type-checker is assumed to fail on them.  Attributes are 
normally attached to something.  Here you mention the need for an 
ignorable extension.  I don't think we want to introduce a third notion. 
  A solution would be to say that contrary to "algebraic structures" 
(expressions, type expressions, patterns), attributes within structures 
are not attached to structured items but are just part of the sequence 
of items of the structure.  So they would be more like extension nodes, 
but silently ignored by the type-checker.  We could then have the 
convention that an attribute placed after a structure item might pertain 
to it.  "ocamldoc" could then use some attributes for section delimiters 
and other attributes to document structure items.  Do you think this is 
an interesting direction?


Alain