Add syntax for higher order quote pattern holes

[nicolasstucki]

• Make typer explicitly type higher-order quasiquotes
• Add higher-order quasi-pattern concept to the Matcher (avoid ambiguities with splice applied to arguments)
• Introduce unambiguous syntax for higher-order quasi-patterns
• Add documentation

case ${ val a = 3; $body(a): Int } => // higher-order quasi-patterns
case ${ val a = 3; ${fn}(a): Int } => // match an application 

[nicolasstucki]

As discussed offline, we will try to encode it with the syntax

case ${ val a = 3; ${body}{a}: Int } => 

[nicolasstucki]

Note that there is a possible improvement for multiple parameters if we allow commas in block in the parser ${f}{x,y,z}.

[odersky]

I am still not sure about the best syntax. My original proposal was to use

$body{y}

for the instantiated splice, and to reserve ${body}{y} for the case body should be spliced as is and then be applied to the block {y}. But it gets ugly for multiple parameters. I am a fan of neither of the alternatives

$body{y, z}
$body{(y, z)}

The first uses a comma in a block, which never happens otherwise and the second looks like (y, z) is a tupled argument where it is not. If we have to choose, I'd go for the first.

But before settling on this, a question: If we leave it as

$block(y)

how often (relatively speaking) is this a higher-order hole? If that's the common case, can we maybe live with the fallback

${block}(y)

for the uncommon case where $block is spliced in front of the literal argument list (y)?

[odersky]

We should have another discussion about the best syntax.

[nicolasstucki]

@odersky I updated the syntax to the one we discussed in the weekly meeting.

[odersky]

Otherwise LGTM