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

[Alain Frisch]

On 03/06/2013 04:17 PM, Xavier Clerc wrote:
> I will not discuss the syntax per se, but I wonder whether
> having both prefix and suffix attributes is not error-prone.
> Could you elaborate on the need of having both?

I proposed to use a prefix attribute (on an include statement) to create 
ocamldoc sections:

[^^doc section "Section Title"] include
    ...
end

but I now tend to prefer "floating" attributes in signatures.

Gabriel gave another example to justify the need for a prefix syntax:

  begin [: pragma(non_exhaustive_match) :]
     ...
  end

but this might be subsumed by the special form:

    begin[@id expr] ... end

which is equivalent to:

   (...)[@id expr]


Do people see use cases where the prefix syntax is much better?

> Another, unrelated question: as an extension developer, it
> seems that I will have to deal with full-fledged expressions
> as attributes values. Do you plan some mechanism to allow
> easy access to an identifier used in such an expression.
> I mean, it can even refer to another module. This also implies
> that you could create dependencies between modules solely
> through attributes; is that correct?

Expressions used inside attributes/extension nodes are just syntactical 
expressions.  They are never type-checked and their identifiers are not 
resolved; ocamldep does not look inside those expressions.

We could use any "universal" type instead of expressions (strings, 
s-expressions, xml, json).  Some arguments to use OCaml expressions:

  - This is a rich language, in which we can encode various DSL 
understood by extensions, so that the extensions don't need to do any 
parsing.

  - We already have a parser!

  - The syntax will look familiar to OCaml developers and adapting 
editors to nicely support (colors, indentation, etc) them will be easy.

  - It won't be uncommon to embed fragments of OCaml code, to be 
inserted into the real code fed to the compiler, within those 
expressions. Example:

   type t = {
      x: int;
      y [@default (x + 1)]: int;
      z [@optional]: int option;
   } [@@builder {with_labels; invariant=(x <= y)}]

  rewritten to:

   type t = {
      x: int;
      y: int;
   }

   let build_t ~x ?(y = x + 1) ?z () =
      assert(x <= y);
      {x; y; z}



As an extension developer, you don't need to suffer from the complexity 
of OCaml expression.  Instead,  you are free to define the subset of 
OCaml expressions which make sense inside "your" attributes/extension 
nodes, and fail when the user doesn't comply with this constraint.