[ghc-steering-committee] Discussion about "Type Application in Patterns" (#126)
Richard Eisenberg
rae at cs.brynmawr.edu
Fri Aug 17 16:16:38 UTC 2018
The rule is this, implemented in the lexer:
With -XTypeApplications on, the character immediately before an @ determines how it is lexed.
1. If the character is a legal end-of-identifier character (respecting the state of the -XMagicHash flag), then the @ is an as-pattern.
2. Otherwise, then the @ is the beginning of a type application.
I abbreviate the rule as talking about whitespace sensitivity, because if the character preceding the @ is, say, a +, then we lex +@ as a user-defined operator.
This rule has been implemented since GHC 8.0 and applies in patterns as well as expressions. I don't think anyone noticed. :) So it works reasonably well. It's a silly rule and I'd be happy to do better, but I don't think it's strictly necessary to aim for better here.
It would be reasonable to warn when a user writes an as-pattern that doesn't conform to this rule (with -XNoTypeApplications).
Richard
> On Aug 17, 2018, at 1:37 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> Hi Richard,
>
> Am Donnerstag, den 16.08.2018, 22:28 -0400 schrieb Richard Eisenberg:
>> Considering this future of relaxed ordering requirements on data
>> constructors isn't compulsory, but I do think it's better if we don't
>> paint ourselves into a corner around this.
>
> I agree.
>
> But so what do we do? Already now require that there is no space
> between @ and the following token when the user wants to use type
> applications in the pattern?
>
> And would we also require the user to add a space after an at-pattern?
> In which case we should probably start a deprecation cycle for the
> currently legal
>
> foo (a @b) = …
>
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
> mail at joachim-breitner.de
> http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
More information about the ghc-steering-committee
mailing list