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

[Leo White]

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

This won't work, because you need to be able to replace Line.present
with an arbitrary type expression.

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

This isn't an extension node, so may be silently ignored.

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

This doesn't make it clear that "< seq: Line.present; source:
Line.present >" is not actually an object type, but an argument to the
sh extension.

> 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?

I don't really know about that specific example. It looks a bit like the
syntax extension was never really deployed for users.

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

Not off the top of my head, but I would have thought that extension
nodes in type expressions would often want to be built from other type
expressions, and there is no easy way to do that at the moment.

> 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.)

I see two uses:

i) Type extensions that take some arguments that are not types:

  [%foo true: 'a list] list

ii) Extensions that define values (although in this case the extra
brackets are fine):

  [%def foo : int list]

> 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?

So far, I've found that (with the exception of Gabriel's extension)
pattern extensions can be easily changed into "match" and "let"
extensions:

  match%ext foo with
    Pattern _ [@ext transform] -> ...
  | ...

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

I suspect that this specific extension is a very unusual case, and it
would be better integrated into the language proper.