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

[Xavier Clerc]

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

Thanks for the clarification. However, I am now afraid about user side...
Expression will be treated in a non-uniform way by attributes.
Moreover, replacing a literal constant with a symbolic one will cause
extension to stop working. Honestly, I cannot say if it is a big deal.
But, I think it can be a surprise.


Xavier Clerc