[wg-camlp4] Negative field report: extension points unsuited for (matches p when e)

[Alain Frisch]

On 05/04/2013 03:27 PM, Leo White wrote:
> I've been going through the uses of camlp4 in opam and recording how
> each of their syntaxes could be adjusted to fit ppx. (I've been doing it
> on and off for a few weeks, and am about half-way through them). One
> group of extensions that would currently need quotations are those that
> create types from other types. For example, the following quotation from
> shcaml:
>
>    <| seq: Line.present; source: Line.present >
>
> this quotation is supposed to be a type expression, where the body of
> the quotation is essentially an object type.

Possible syntaxes:

  [%sh (seq: Line.present); (source: Line.present)]

  < seq: Line.present; source: Line.present > [@sh]

  [%sh] * < seq: Line.present; source: Line.present >

But, in that specific case, is the syntactic sugar worthwhile at all? 
Reading the shcaml documentation 
(http://www.eecs.harvard.edu/~tov/code/shcaml/doc/),  I can see this 
syntax used only in inferred types, and not documented.  Do the users 
really need to write those types?

Can you give other examples of these extensions which would benefit from 
the ability to use type expressions as arguments of extensions or 
attributes?

> For cases like these, I thought it would be a good idea to change from
> having expressions as bodies, to having the bodies be like a
> simple type constraint:
>
>    [%id expr : core_type]
>
> where both the expression and the "constraint" are optional.

Just to be sure that I understand your proposal correctly, you would 
support:

   expr
   expr : core_type
   : core_type

Do you have concrete examples where the second form would be nice? 
(Adding parentheses makes it a valid expression anyway.)

Gabriel reported a case (pa_matches) where allowing patterns (and also 
patterns with a "when" guard) would be useful as well.  Would you 
suggest to allow patterns (with a dedicated syntax) as well?

> Do you think that we could support this form as well as structures?  If
> not, did you have any specific cases that you wanted to use structures
> for?

In addition to top-level extensions and a more natural support for empty 
arguments (the empty structure), I can imagine a general form
of "local structure items":

   let [%local STR] = () in e
====>
   let module LOCAL001 = struct STR let res = e end in
   LOCAL001.res

to allow, for instance:

  let [%local exception M] = () in
  ....

  let [%local type t = {x: int; y: string}] = () in
  ....




Alain