[wg-camlp4] My no-use of camlp4 syntax extensions for Otags

[Hendrik Tews]

Alain Frisch <alain.frisch at lexifi.com> writes:

   > There might however be cases with the danger of wrong
   > generalization. What I mean with this is the following: The
   > ocamlast tool only works on correct OCaml code. I cannot feed
   > it with "assert _ " in order to get the most general ast
   > tree for assertions. So instead I have to feed it with, for
   > instance, "assert true" and get Pexp_assert ... I might now
   > believe that "assert false" is also represented with Pexp_assert,
   > which is wrong.

I forgot to note, that "assert false" is of course a bad example.
With Pexp_assertfalse standing next to Pexp_assert, everything is
clear in this case.

   > For documentation need (2), ocamlast is not really a help. For
   > (2) I would suggest to annotate each constructor in parsetree.mli
   > with the concrete syntax. For instance
   >
   >    | Pexp_while of expression * expression
   >       (** while <expression> do <expression> done *)

   Good idea. I've started with type expressions:

This is precisely the kind of documentation that I was asking
for. Good that you also integrated side conditions, eg n >=2 for
Ptyp_tuple. 

   > There are probably a lot of side conditions. For
   > instance, "expr_1; expr_2; expr_3" is
   > Pexp_sequence(expr_1, Pexp_sequence (expr_2, expr3) and not
   > Pexp_sequence( Pexp_sequence(expr_1, expr_2), expr3) (or vice
   > versa).

   (e1; e2; e3) is indeed parsed as (e1; (e2; e3)), but ((e1; e2); e3)
   will be represented as you expect (confirmed by ocamlast).  I don't
   think it is worth documenting again the definition of the Parsetree
   disambiguation and associativity rules; this is already done in the
   manual, and rules can be discovered with ocamlast.

   Moreover, I'd argue that authors of ppx extensions don't really need
   to be familiar with this topic, since they operate on abstract syntax.
   What's important is rather to specify invariants on the Parsetree data
   structure, especially those which are not checked by the type-checker.
   (And we should probably strengthen the type-checker to test more of
   those conditions such as the validity of identifier strings, etc.)

The sequence example is bad. I simply mean that 
side conditions / invariants should be mentioned. First, for
constructing ast's that will not cause the compiler to crash. But
also for ignoring irrelevant cases when pattern matching on an
ast.

   > You could write the documentation for (1) and (2) in comments or
   > ocamldoc comments in the source files. However, I would prefer
   > something like a wiki page, where we users can immediately
   > contribute.

   Authors of ppx extensions are probably going to have parsetree.mli
   under they eyes quite often.  It seems good to me to put some
   documentation directly there.  Which is not to say that an external
   wiki won't be useful as well.

I suggested a wiki because, in the past, it took sometimes ages
to get the documentation fixed. But if the documentation in
parsetree.mli is complete and if changes are integrated in
reasonable time, then a wiki is superfluous.

Bye,

Hendrik