Add support for invisible type patterns in lambda and \cases expressions
#205
Labels
Comments
RyanGlScott
added a commit
that referenced
this issue
Apr 30, 2024
This is a partial fix for #205 which adds a `DInvisP` data constructor to `DPat`, which behaves exactly like `InvisP` in the `template-haskell` AST. This is only a partial fix, however, because `DInvisP` is currently only supported in the clauses of function declarations. In particular, `DInvisP` is _not_ supported in lambda expressions or `\cases` expressions. See the "Known limitations" section of the `README` for more. In order to add full support for `DInvisP`, we would first need to implement the design proposed in #210. Until then, this is good enough.
RyanGlScott
added a commit
that referenced
this issue
May 1, 2024
This is a partial fix for #205 which adds a `DInvisP` data constructor to `DPat`, which behaves exactly like `InvisP` in the `template-haskell` AST. This is only a partial fix, however, because `DInvisP` is currently only supported in the clauses of function declarations. In particular, `DInvisP` is _not_ supported in lambda expressions or `\cases` expressions. See the "Known limitations" section of the `README` for more. In order to add full support for `DInvisP`, we would first need to implement the design proposed in #210. Until then, this is good enough.
RyanGlScott
changed the title
\cases expressions
|
#211 implemented partial support for invisible type patterns. You can now desugar invisible type patterns in function clauses, but not in lambda expressions or |
RyanGlScott
added a commit
that referenced
this issue
May 23, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
RyanGlScott
added a commit
that referenced
this issue
May 23, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
RyanGlScott
added a commit
that referenced
this issue
May 24, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
RyanGlScott
added a commit
that referenced
this issue
May 24, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
RyanGlScott
added a commit
that referenced
this issue
May 24, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
RyanGlScott
added a commit
that referenced
this issue
Jun 1, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
RyanGlScott
added a commit
that referenced
this issue
Jun 1, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
RyanGlScott
added a commit
that referenced
this issue
Jun 5, 2024
This patch deprecates the `DLamE` and `DCaseE` data constructors of `DExp` in favor of a new `DLamCasesE` data constructor, which represents `\cases` expressions. Moreover, `th-desugar` now desugars all lambda, `case`, `\case`, and `\cases` expressions to `DLamCasesE`. There are several reasons why this is desirable, but an especially important motivation for switching is to support desugaring expressions that use embedded type patterns (see #204) or invisible type patterns (see #205) in lambda, `case`, `\case`, and `\cases` expressions. This is a pretty big change, even by `th-desugar` standards. As such, I have made an effort to avoid some of the more extreme breaking changes for now. For example, I have refrained from removing `DLamE` and `DCaseE` outright, instead converting them to deprecated pattern synonyms. I have also introduced combinators such as `dLamE` and `dCaseE`, which construct lambda-like and `case`-like expressions in terms of `DLamCasesE`. For the full details on how to migrate your code over to use `DLamCaseE`, see the new `doc/LambdaCaseMigration.md` document. This patch: * Fixes #210 (by replacing `DLamE`/`DCaseE` with `DLamCasesE`) * Fixes #204 (by supporting higher-order uses of embedded type patterns) * Fixes #205 (for supporting higher-order uses of invisible type patterns) This also adds regression tests for #204 and #205.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
GHC 9.10 introduces the ability to use invisible type patterns. As such, examples like this can now be written:
As a preliminary, we'd need a
th-desugarcounterpart toInvisP, which was introduced intemplate-haskell-2.22.0.0(shipped with GHC 9.10.1):Note that
@-binders can also be used in lambda expressions and\casesexpressions, which means that it is possible to write things like the following:This means that
@-binders are susceptible to challenges (1) and (2) from #204. (Thankfully, it's not susceptible to challenge (3), since invisible type patterns are always clearly marked with@.)The text was updated successfully, but these errors were encountered: