Untyped Template Haskell quotes as patterns #529

Ericson2314 · 2022-08-05T14:26:18Z

The Template Haskell AST is inherently unstable. Let's make that less of an issue. We can do that by allowing Quotes to be used instead of Template Haskell AST data constructors in patterns.

Rendered

…posals#285

Can flush out with quick summaries later

david-christiansen · 2022-08-09T18:59:55Z

A few questions about the interpretation of quotation patterns:

Would you allow any of the following, and would they recognize precisely the lambda expressions?

isLambda [| \_ -> $(_) |] = True
isLambda [| \$(_) -> $(_) |] = True

Is isLambdaLambda [| \$(_) -> $(_) -> $(_) |] = True equivalent to isLambdaLambda [| \$(_) $(_) -> $(_) |] = True?

Given that the language in the module that invokes the metaprogram that uses a quotation pattern may be using different GHC extensions than the module in which it occurs, what happens if there's e.g. BlockArguments enabled in just one of them? Are there any sets of incompatible syntactic extensions that would make it impossible to write a metaprogram that matched all possible user syntax?

Ericson2314 · 2022-08-09T22:09:04Z

isLambda [| \$(_) -> $(_) |] = True

Returns True for any single parameter lambda. This is allowed.

isLambda [| \_ -> $(_) |] = True

Returns True for any lambda with a single _ parameter. Not the same!

Is isLambdaLambda [| \$(_) -> $(_) -> $(_) |] = True equivalent to isLambdaLambda [| \$(_) $(_) -> $(_) |] = True?

I assume you meant isLambdaLambda [| \$(_) -> \$(_) -> $(_) |] = True for the first one? (Note the second \ I added.)

Those would not be equivalent because the syntax being matched is different even though syntax has the same semantics.

(It would be interesting to do macros that respect various equational theories on syntax, but that is a huge leap from what we have today with Template Haskell. I think it is better to leave that out of scope.)

Instead, I rather create new splicing forms that allow one to e.g. splice (in positive and negative position) a list of parameters. e.g. suppose we could could do

isLambda [| \$(x) $..(_) -> $(_) |] = True

and that would match both

\(Pat foo) -> ignored
\(Pat foo) ignored -> ignored

in both cases binding [p| Pat foo |] as x.

My brief experience with @int-index exploring converting happy to TH (https://github.com/haskell/happy/tree/wip/template-haskell) indicated to me that were greatly lacking expressive power in the sorts of quotes and slices that are permitted --- the $..(thing) example being just one example.

Still, this too I think is best left as future work. We can nail down the core feature now, and then with a good foundation open the floodgates to much more quoting/splicing flexibility, I think that will work better.

proposals/0529-th-quotes-as-patterns.rst

david-christiansen · 2022-08-16T13:47:44Z

WRT the related work in Racket, the gold standard is no longer syntax-case and syntax-rules, but rather syntax-parse, which provides much better error messages along with re-usable sub-patterns. What you're proposing here is something even less powerful than syntax-case, as it won't preserve variable scopes, and I'm not sure we can reasonably implement something like syntax-parse on top of Haskell's pattern syntax. But it is good to know about it, and that we'll likely eventually want something similar.

The relevant paper is "Fortifying Macros" by Culpepper and Felleisen, and there's a Haskell implementation of its core as part of Crucible's concrete syntax.

Thanks to @th-quotes-as-patterns; I am basically just including his comment at ghc-proposals#529 (comment)

Ericson2314 · 2022-08-22T23:25:19Z

Updated to properly distinguish Scheme and Racket :), thanks @david-christiansen

nomeata · 2022-09-07T18:22:47Z

@Ericson2314, are you by any chance attending Haskell Symposium? If so, would you like to present this proposal at the GHC Proposals session?

Ericson2314 · 2022-09-09T23:10:41Z

@nomeata I unfortunately am not going to ICFP --- and feeling some regret right now for sure!

Ericson2314 · 2022-11-15T07:08:02Z

Hmm I guess I forgot to submit this to the committee?

nomeata · 2022-11-15T08:15:17Z

Looks like it :-). Is it ready fonr submission?

Ericson2314 · 2022-11-15T21:46:47Z

@nomeata I think so! I mean to submit it.

Good idea, thanks!

And clarify declaration pattern matching.

int-index · 2022-12-07T05:51:15Z

As far as terminology is concerned, I'd like to suggest to make a distinction between "pattern quotes" and "quote patterns".

Pattern quote: a Template Haskell quote that constructs a pattern, i.e. [p| ... |]
Quote pattern: a pattern that consists of a Template Haskell quote (i.e. the feature proposed here)

Based on this terminology, TemplateHaskellQuotesAsPatterns could be renamed to TemplateHaskellQuotePatterns.

Ericson2314 · 2022-12-07T13:24:36Z

I like that, @int-index. But moreover I would love to wash my hands of all name bike-shedding, purely following the consensus of others on this one :). So I hope you and @adamgundry can come to a decision on that!

Ericson2314 · 2022-12-11T21:49:36Z

@adamgundry I believe I have addressed most of the issues, except for the naming issue, and expanding the Related Work section.

Perhaps some sort of interactive discussion in what sort of topics would be useful to discuss, so I know what I should delve into.

Maybe a good starting point is also that the Scheme family macros work fundamentally differently, in that that the binding structure is unknown because the syntax is sexpression of unknown meaning until the final splice. Whereas we quote actual Haskell expressions and thus the quote-internal binding structure is known from the get-go, before manipulation. Perhaps therefore the most important one to investigate is Rust, since it is very Racket inspired but does allow quotes of expression etc. (rather than mere "token tree", it's s-expression equivalent) like us.

I am not at all familiar with what Idris and Lean do.

simonpj · 2022-12-12T15:37:06Z

I get the general motivation but lots of things are unclear here.

Is this an extension to untyped Template Haskell, or to typed Template Haskell?
I assume the former, but it would be much better to say so. The important point is that
- Untyped TH splices can appear in patterns (and declarations and types) whereas typed TH splices are always expressions..
- Untyped TH splices run during renaming, whereas typed TH spliced run during type checking.
If it's untyped TH, then it doesn't make so much sense to talk about the typing rules for it.
All we need to know is that any nested splices $p must be for patterns p.
I'd love the relationship to quasi-quotes to be far more explicit. Quasi-quotations (-XQuasiQuotes) are
essentially untyped Template Haskell. The quasi-quote [foo| string |] in an
pattern context is precisely equvalent to $(quotePat foo "string"), where quotePat picks a field from the record foo :: QuasiQuoter.
```
data QuasiQuoter = QuasiQuoter { quoteExp  :: String -> Q Exp,
                                 quotePat  :: String -> Q Pat,
                                 quoteType :: String -> Q Type,
                                 quoteDec  :: String -> Q [Dec] }
```
This splice runs during renaming. For example:
```
f [wombat| hello %x there |] = x+2
```
here the quasiquote [wombat| hello %x there |] expands to a pattern that (presumably) binds x. But the syntax for this binding is entirely under the control of the wombat quasiquoter, which can do whatever it likes.
Currently you can't use e, p, d, or t as the name of a quasiquoter.
- In expression position [e| blah|] is an expression quote of type Q Exp, and [t| blah|] is a type quote of type Q Typ.
- These forms are simply not allowed in pattern position, in types etc.
So the proposal plans to make them meaningful in patterns. Well and good, but say so much more explicitly. It's really as if we are providing a rather special quasi-quoter e for which quotePat e does the thigns described here. Quite nice: fills out out a corner in the design.
There is an awkwardness about binding. Consider
```
f n = blah

h x = [e| Just $(f 2) |]

g [e| ($x,  $(f 2)) |] = ...
```
In a normal expression splice, like in the RHS of h, the f is a bound occurrence of f, and the splice $(f 2) is run to compute the syntax tree to plug in instead of $(f 2).

But what about in patterns? I think the $x is a binding occurrence; and I think
that the splice $(f 2) is perhaps illegal, because it is understood as a pattern.
(I think that is what the crypic statement "The second difference is that splices within these quotes contain patterns instead of expressions" means.)

That means that splices in pattern-quotes can do no computation (unlike splices in expression-quotes). Maybe that's ok.
"The third and final difference is that names in quotes must all be uses, never bindings." I have no idea what this means.

adamgundry · 2022-12-20T20:49:05Z

@simonpj

"The third and final difference is that names in quotes must all be uses, never bindings." I have no idea what this means.

The examples point out that binding a name inside a quote-as-pattern is disallowed, so this is rejected because of the binding occurrence of x:

f [| \x -> x |] = ...

There is a bit more discussion of this in the Alternatives, section 6.2. The point is that picking the right semantics for such bindings seems nontrivial, so the proposal defers committing to a semantics.

adamgundry

Shepherd here. I've reviewed the updates and made a few more suggestions. Once @Ericson2314 has had a chance to look at these and @simonpj's comments, I'm inclined to recommend acceptance to the committee.

One other broad point: I'm a little worried that the implementation effort required for this proposal might be nontrivial. The Motivation section is clear when it comes to quotes of expressions, but could more clearly motivate support for quotes of other syntactic categories (notably declarations, where the restrictions on binding names seem to bite hard, and the fact that there may be more than one declaration needs thought). I can see that symmetry and consistency is one motivation, but are there motivating examples involving the other syntactic categories?

adamgundry · 2022-12-20T20:17:46Z

proposals/0529-th-quotes-as-patterns.rst

+Note we do have quotes *of patterns* today (``[p| ... |]``), but that is orthogonal.
+This is quotes *as patterns*, the type of syntax being quoted doesn't matter and could be anything.
+The point is the quotes are in negative position.
+
+With this change put together, the hope is that a significant portion of TH out in the wild is going to be more stable across GHC versions.
+This is all accomplished without trying to minimize TH AST changes, which is quite a hopeless task and also a perverse incentive for the rest of language development.


My point wasn't that quasiquotes make this proposal superfluous: rather, quasiquotes can already generate patterns (quotePat returns a Q Pat) so it makes sense to extend this to TH quoters. (This is Simon's point 3 in #529 (comment).)

adamgundry · 2022-12-20T20:25:29Z

proposals/0529-th-quotes-as-patterns.rst

+
+- https://arxiv.org/pdf/2001.10490.pdf
+
+Future Work


I thought about this some more, and realised that ideally we would want TExp to be a GADT, so that pattern-matching a TExp a with [|| \ $(x) -> $(y) ||] would refine a to be a function type. This seems hard. But it's fine to have this proposal be about Untyped TH and leave TTH for future work. 😁

adamgundry · 2022-12-20T20:27:03Z

proposals/0529-th-quotes-as-patterns.rst

+Relax the rules so that TH Quotes only impose a ``Quote`` constraint when ``newName`` is in fact needed.
+Otherwise, merely impose a ``Monad`` constraint.
+
+[This was a `alaternative that was rejected <./0246-overloaded-bracket.rst#alternatives>` of Proposal #246, but now we have additional movation for it (as detailed in "Effectas and Interactions") below.]


Suggested change

[This was a `alaternative that was rejected <./0246-overloaded-bracket.rst#alternatives>` of Proposal #246, but now we have additional movation for it (as detailed in "Effectas and Interactions") below.]

[This was an `alternative that was rejected <./0246-overloaded-bracket.rst#alternatives>`_ of Proposal #246, but now we have additional motivation for it (as detailed in "Effects and Interactions") below.]

adamgundry · 2022-12-20T20:34:28Z

proposals/0529-th-quotes-as-patterns.rst

+- ``[| ... |]`` or ``[e| ... |]``, where "..." is an expression, is a pattern that matches ``Exp``
+- ``[p| ... |]``, where "..." is a pattern, is a pattern that matches ``Pat``
+- ``[t| ... |]``, where "..." is a type, is a pattern that matches ``Type``
+- ``[d| ... |]``, where "..." is a top-level declaration, is a pattern that matches a ``List Dec`` with a single item.


I'm wondering about this restriction to a single item. Why is that needed? It seems a bit inconsistent with the fact that that quotes of declarations as expressions (and quasiquotes yielding declarations) may have multiple declarations.

adamgundry · 2022-12-20T20:39:13Z

proposals/0529-th-quotes-as-patterns.rst

+For example, De Bruijn indices encode actions in a way that makes equality between the actions *themselves*, rather than their results, easily decidable.
+This would be a less hacky solution.
+
+Note that without this alternative, we still don't have to full back completely on not using our new feature for this use-case.


Suggested change

Note that without this alternative, we still don't have to full back completely on not using our new feature for this use-case.

Note that without this alternative, we still don't have to fall back completely on not using our new feature for this use-case.

adamgundry · 2022-12-20T20:44:23Z

proposals/0529-th-quotes-as-patterns.rst

+The third and final difference is that names in quotes must all be uses, never bindings.
+The semantics of matching a name, either standalone, or inside a larger quote, is name equality.
+This is formalized on the deguaring of a case alternative below::


Suggested change

The third and final difference is that names in quotes must all be uses, never bindings.

The semantics of matching a name, either standalone, or inside a larger quote, is name equality.

This is formalized on the deguaring of a case alternative below::

The third and final difference is that names in quotes must all be uses, never bindings.

The semantics of matching a name, either standalone, or inside a larger quote, is name equality.

This is formalized by the desugaring of a case alternative below::

adamgundry · 2022-12-20T21:14:56Z

proposals/0529-th-quotes-as-patterns.rst

+Quotes as patterns
+~~~~~~~~~~~~~~~~~~
+
+With the new extension ``TemplateHaskellQuotesAsPatterns``, slightly modified quotes are usable in pattern position.


I see that @int-index also had a suggestion in #529 (comment), although my inclination is still to have explicit prepositions rather than relying on word order to distinguish "pattern quote" from "quote pattern". I'm happy to leave the bikeshed colour to be resolved later once the substance of the proposal is agreed, though.

I still think it would be helpful to have some explicit definitions, something like (with the current terminology):

A quote is said to be of the syntactic category being quoted, for example [e| ... |] is a quote of an expression and [p| ... |] is a quote of a pattern. Template Haskell already supports quotes of expressions, patterns, types and declarations, plus quotes of arbitrary syntax via quasiquotes.

A quote is said to be used as the syntactic category in which it occurs, for example x = [...| ... |] includes a quote as an expression whereas f [...| ... |] = ... includes a quote as a pattern. Template Haskell currently supports quotes as expressions and quasiquotes as all four categories; this proposal adds quotes as patterns.

Thus in f [t| Bool |] = [d| data T |] we have a quote of a type as a pattern and a quote of a declaration as an expression.

nomeata · 2023-01-19T16:02:39Z

Should we mark this as “needs revision”?

Ericson2314 · 2023-01-19T16:08:08Z

Yes please. And I had written it for HF consideration but it is now pretty far down in the future work on the draft proposal I am working on so it feels less urgent (perhaps I shouldn't have submitted it to the committee).

I am glad I wrote it, I am thankful @adamgundry reviewed it, but I feel less urgency pushing it to completion until the lower hanging fruit we can do re template-haskell compatibility (e.g. record fields as @bgamari pointed out) is plucked. I still think it is a good idea to do eventually, but as the saying goes "walk before you run".

adamgundry · 2023-01-19T20:28:38Z

Thanks for this @Ericson2314, I'm happy to label this as "needs revision" for now and wait for you or another willing volunteer to decide to pick it up and get it over the line. As I indicated I think this is basically a solid idea, albeit a nontrivial one to implement and with a few interesting corners to discuss. 😄

sgraf812 · 2023-06-13T16:09:29Z

As we discussed on Sunday (Ben's notes) and as the proposal states, writing such "quote patterns" is a great way for users that use TH for the macros/grammar use case (as opposed to the staging/code gen use case) to define their macros in a way that is far less susceptible to churn in the TH AST, plus it is far more ergonomically to use. Perhaps the discussion on Sunday would re-ignite @Ericson2314's interest on the matter?

As far as bike-shedding is concerned, I'd like to throw "Quotes in matches" or "matching quotes" into the ring. That expresses that these things must occur in a meta level pattern match, in "negative" position. There is no risk of confusing that with "Quote patterns" or "pattern quotes" where which is which I already forgot since I started this post. Unfortunately, a match is already a name describing the syntactic construct that encompasses a pattern and its GRHSs so that name isn't optimal either.

Perhaps we should take strong inspiration in https://docs.racket-lang.org/guide/pattern-macros.html (Edit: Or even the more closely related syntax-case: https://docs.racket-lang.org/guide/syntax-case.html). Example

foo :: Int -> Int
f [| foo (2*$(x)) |] = [| 2 * foo $(x) |]

(I hope I got that right.) Here, foo (2*$(x)) is called the pattern and 2 * foo $(x) is called the template. Both the pattern and the template are quoted ([| ... |]) and the quote has different semantics based on whether it's quoting a pattern or a template. A template quote that produces a pattern (with the [p|..] quoter) is separate from a pattern quote, which is a meta-level pattern taking the syntactic shape of a quote. As the proposal states, pattern quotes match on pure AST expressions whereas template quotes have monadic type.

Template Haskell used to have template quotes only, now it also got pattern quotes. (Makes you wonder if the name still flies.)

I don't think it makes sense to call f a pattern-based macro as defined by syntax-rules, because that term would apply to foo if f were automatically applied everywhere in the program; we currently lack such automated extension of the meta-level grammar (which in Racket you apparently do with define-syntax).

Rather, as @david-christiansen points out in #529 (comment), this proposal is quite similar to syntax-case (which is used to define syntax-rules).
David also points out that newer Rackets use a new thing called syntax-parse. Here are a few examples: https://school.racket-lang.org/2019/plan/tue-mor-lecture.html Indeed, syntax-parse seems pretty similar to typical uses of Template Haskell, too. I think the biggest difference is the notion of an actual syntax tree where and the ways in which you can tweak syntax-parse with directives, for example for better error info. I think we could have something similar by allowing type annotations to filter for specific kinds of matches, e.g.,

foo :: Int -> Int
f [| foo (2*$(x :: VarP)) |] = [| 2 * foo $(x) |]

Which certainly is a potential extension to this proposal.

Edit: Clarification on syntax-rules, syntax-case and syntax-parse. I still think I've got some of the definitions here wrong, though.

sgraf812 · 2023-06-13T16:15:22Z

proposals/0529-th-quotes-as-patterns.rst

+
+Quotes as Patterns
+~~~~~~~~~~~~~~~~~~
+


Empty subsection. Intended?

sgraf812 · 2023-06-13T16:16:08Z

proposals/0529-th-quotes-as-patterns.rst

+
+   because matching on lists of multiple declarations is left as future work.
+
+Optional: Fine-grained Quotation constraints


I think this can and should be a separate proposal. Perhaps move to Future Work instead?

sgraf812 · 2023-06-13T16:18:18Z

proposals/0529-th-quotes-as-patterns.rst

+Effect and Interactions
+-----------------------
+
+``TemplateHaskell`` will not imply ``TemplateHaskellQuotesAsPatterns``, though it does imply ``TemplateHaskellQuotes``.


I think I'd prefer something like -XPatternQuotes after my reflection in #529 (comment). No need to include the then misnomer TemplateHaskell.

sgraf812 · 2023-06-13T16:20:03Z

proposals/0529-th-quotes-as-patterns.rst

+~~~~~~~~~~~~~~~~
+
+The lack of symmetry where expression create actions but patterns only bind plain AST values is annoying.
+But the fixes for this might be too radical?


I didn't understand what you meant here at first. IMO, give examples or move to Future Work!

sgraf812 · 2023-06-13T16:22:30Z

proposals/0529-th-quotes-as-patterns.rst

+Pattern match on actions(!)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+I hypothesize that we could do better than the proposed actions vs no action asymmetry by meditating on the ways pattern matching relates to optics.


Why is this an alternative? Can't we have both? I'm not convinced that we want, though; seems confusing and almost no benefit (could just write the traverse form). Future Work?

sgraf812 · 2023-06-13T16:37:58Z

proposals/0529-th-quotes-as-patterns.rst

+Support local variables
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Quotes that bind local variables do in fact have an interpretation as non-linear patterns::


I think this section is confusing for these reasons:

It discusses an extension to this proposal, namely binding constructs in patterns, that would be reasonable to implement in the future. So it belongs in Future Work.

It calls these matches "non-linear", but of course the resulting desugaring is not non-linear in the meta language, as you readily point out.

If this really were about non-linear matches, I'd totally expect __x1 == __x3 to hold.

Besides, I think the semantics you describe is very reasonable, because it allows for the expected round-tripping property: If I define

f [| (\x -> x, \x -> x) |] =... ... $(f [| (\x -> x, \x -> x) |] ... ... $(f [| (\z -> z, \z -> z) |] ... ... $(f [| (\a -> a, \b -> b) |] ...

Then I would expect all uses of f to match. Is that how it works in Racket and Lean, @david-christiansen @Kha?

In macro systems like Racket's and Lean's, you cannot distinguish between bindings and uses in quotations because scoping is discovered only during expansion. So "quotes that bind local variables" is not even something we can detect in those systems.

I presume "discovered only during expansion" is an artifact of the fact that Racket-style macros will not get a name-resolved TH AST as input (where we know the binding structure but limit ourselves to macro syntax expressible in Haskell) but rather just a concrete syntax tree. Perhaps let me rephrase in terms of the example in https://school.racket-lang.org/2019/plan/tue-mor-lecture.html:

(define-syntax (robust-for/list5 stx) (syntax-parse stx [(_ ([elem-name:id seq]) computation) #'(map (λ (elem-name) computation) seq)]))

This macro will expand (robust-for/list5 ([x (list 1 2)]) (add1 x)) to (map (λ (x) (add1 x)) (list 1 2)), matching [elem-name :-> x, seq :-> (list 1 2)]. Note that elem-name is ultimately spliced into a binding occurrence and that computation may refer to the instantiation of elem-name, thus its syntax class is specified to be id, which is what elem-name:id does. (This is somewhat like pushing an expected type for the AST node to match inside the pattern, I guess, where "type" in Racket really means a user-definable non-terminal of the extensible syntax. See 5.6 in the link above.) But the pattern (_ ([elem-name:id seq]) computation) does not know about binding structure at all; rather the macro equips the pattern with a binding structure post-hoc when it generates the template (map (λ (elem-name) computation) seq)])) for the pattern, thus intentionally capturing occurrences of elem-name in computation.

That's exactly right. It's the same reason I mentioned in the ZuriHac discussion why our macros are untyped (on the level of the quoted language) but core-level transformations can optionally be typed (which is done by https://github.com/gebner/quote4 btw).

sgraf812 · 2023-06-13T16:43:26Z

proposals/0529-th-quotes-as-patterns.rst

+  f [|| $$(x) $$(y) ||] = ... :: delta
+
+``x`` would be bound as ``x :: Code m (beta -> alpha)``, and
+``y`` would be bound as ``y :: Code m beta``.


Tricky, and good thinking. Perhaps you need Monad m => or Applicative m => to have access to pure.
@mpickering probably knows what to do here; altough typed macros are probably not a priority to TTH (which focuses on staging).

sgraf812 · 2023-06-13T17:45:23Z

proposals/0529-th-quotes-as-patterns.rst

+
+None at this time.
+
+Related Work


Correct me if I'm wrong, but since the proposal currently does not allow matching on binding constructs, we can't make hygiene better or worse. Judging from an hour worth reading, I also don't think we lock ourselves out with this proposal to more modern approaches such as syntax-parse because the stated semantics should be a subset of whatever advanced stuff we will happen to want in the future.

Ericson2314 added 12 commits June 11, 2022 17:27

th-quotes-as-patterns: Copy Template

438feae

th-quotes-as-patterns: 1st draft of motivation

9d167f1

th-quotes-as-patterns: 1st draft of rest

82f9890

th-quotes-as-patterns: Fix typos

48d5d7c

th-quotes-as-patterns: Fix Extension name, extend example

91496fc

th-quotes-as-patterns: Tidy up proposed change

422d2ef

th-quotes-as-patterns: Fix typo

e979a42

th-quotes-as-patterns: 1 sentence on proposed change in summary

0c7617d

th-quotes-as-patterns: Expand implementation plan with ref to ghc-pro…

02c8fdf

…posals#285

th-quotes-as-patterns: Rename now that we are assigned number

6a8f8d0

th-quotes-as-patterns: Set up PR backlink

e5b867d

th-quotes-as-patterns: Add some links to related work

cfb9606

Can flush out with quick summaries later

th-quotes-as-patterns: Fix some reST

f08d8b9

TeofilC reviewed Aug 16, 2022

View reviewed changes

proposals/0529-th-quotes-as-patterns.rst Outdated Show resolved Hide resolved

Ericson2314 and others added 2 commits August 22, 2022 15:54

Update proposals/0529-th-quotes-as-patterns.rst

168107e

th-quotes-as-patterns: Distinguish Racket state-of-the-art from Scheme

889fc1f

Thanks to @th-quotes-as-patterns; I am basically just including his comment at ghc-proposals#529 (comment)

nomeata changed the title ~~Template Haskell quotes as patterns~~ Template Haskell quotes as patterns (under review) Nov 16, 2022

nomeata added the Pending shepherd recommendation The shepherd needs to evaluate the proposal and make a recommendataion label Nov 16, 2022

nomeata assigned gridaphobe and adamgundry and unassigned gridaphobe Nov 16, 2022

Ericson2314 added 2 commits December 6, 2022 16:19

529: Add examples from discussion thread

803039f

Good idea, thanks!

529: Add example of non-expression quotes as patterns

6788cba

And clarify declaration pattern matching.

Ericson2314 force-pushed the th-quotes-as-patterns branch from 48f23b4 to 6788cba Compare December 6, 2022 21:37

Ericson2314 added 7 commits December 6, 2022 16:44

529: Fix crazy traversable alternative

7b93445

529: Expanded on second alt as suggested

d140eea

529: Clarify independency of extensions

3b828a0

0529: Use BNF for grammar

500b938

529: Add typed TH as future work

8456fff

529: Quotes of names as patterns too!

0390085

529: Missing word

24f3a81

adamgundry added Pending shepherd recommendation The shepherd needs to evaluate the proposal and make a recommendataion and removed Needs revision The proposal needs changes in response to shepherd or committee review feedback labels Dec 12, 2022

bgamari mentioned this pull request Dec 12, 2022

Standard library reform: Split base haskellfoundation/tech-proposals#47

Closed

Ericson2314 changed the title ~~Template Haskell quotes as patterns (under review)~~ Untyped Template Haskell quotes as patterns (under review) Dec 12, 2022

adamgundry reviewed Dec 20, 2022

View reviewed changes

adamgundry added Needs revision The proposal needs changes in response to shepherd or committee review feedback and removed Pending shepherd recommendation The shepherd needs to evaluate the proposal and make a recommendataion labels Jan 19, 2023

Ericson2314 mentioned this pull request Feb 7, 2023

Stabilising template-haskell haskellfoundation/stability#16

Open

sgraf812 reviewed Jun 13, 2023

View reviewed changes

adamgundry removed their assignment Jan 22, 2024

adamgundry changed the title ~~Untyped Template Haskell quotes as patterns (under review)~~ Untyped Template Haskell quotes as patterns Jan 22, 2024

	[This was a `alaternative that was rejected <./0246-overloaded-bracket.rst#alternatives>` of Proposal #246, but now we have additional movation for it (as detailed in "Effectas and Interactions") below.]
	[This was an `alternative that was rejected <./0246-overloaded-bracket.rst#alternatives>`_ of Proposal #246, but now we have additional motivation for it (as detailed in "Effects and Interactions") below.]

	Note that without this alternative, we still don't have to full back completely on not using our new feature for this use-case.
	Note that without this alternative, we still don't have to fall back completely on not using our new feature for this use-case.


		because matching on lists of multiple declarations is left as future work.

		Optional: Fine-grained Quotation constraints

Untyped Template Haskell quotes as patterns #529

Are you sure you want to change the base?

Untyped Template Haskell quotes as patterns #529

Conversation

Ericson2314 commented Aug 5, 2022 • edited

david-christiansen commented Aug 9, 2022

Ericson2314 commented Aug 9, 2022 • edited

david-christiansen commented Aug 16, 2022

Ericson2314 commented Aug 22, 2022 • edited

nomeata commented Sep 7, 2022

Ericson2314 commented Sep 9, 2022

Ericson2314 commented Nov 15, 2022

nomeata commented Nov 15, 2022

Ericson2314 commented Nov 15, 2022 • edited

int-index commented Dec 7, 2022 • edited

Ericson2314 commented Dec 7, 2022

Ericson2314 commented Dec 11, 2022

simonpj commented Dec 12, 2022

adamgundry commented Dec 20, 2022

adamgundry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nomeata commented Jan 19, 2023

Ericson2314 commented Jan 19, 2023 • edited

adamgundry commented Jan 19, 2023

sgraf812 commented Jun 13, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ericson2314 commented Aug 5, 2022 •

edited

Ericson2314 commented Aug 9, 2022 •

edited

Ericson2314 commented Aug 22, 2022 •

edited

Ericson2314 commented Nov 15, 2022 •

edited

int-index commented Dec 7, 2022 •

edited

Ericson2314 commented Jan 19, 2023 •

edited

sgraf812 commented Jun 13, 2023 •

edited