[ghc-steering-committee] Discussion about "Type Application in Patterns" (#126)

[Eric Seidel]

I've always thought of "@Int" as a single syntactic unit, so I'd be happy to disallow spaces between the @ and the type.

On Fri, Aug 17, 2018, at 12:21, Simon Peyton Jones via ghc-steering-committee wrote:
> Ha. We could tighten this up further to require a non-blank immediately 
> after the @ for a type application.  Thus
>             f @Int  or    g @(Tree Int)
> but not
>             f @ Int         g @ (Tree Int)
> 
> That would leave (p1 at p2) and (p1 @ p2) free for patterns.
> 
> Simon
> 
> From: ghc-steering-committee <ghc-steering-committee-
> bounces at haskell.org> On Behalf Of Richard Eisenberg
> Sent: 17 August 2018 17:18
> To: Joachim Breitner <mail at joachim-breitner.de>
> Cc: ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] Discussion about "Type Application 
> in Patterns" (#126)
> 
> Note that this rule is documented, in brief, in the manual:
> 
> > A visible type application is preceded with an @ sign. (To disambiguate the syntax, the @ must be preceded with a non-identifier letter, usually a space. For example, read at Int 5 would not parse.)
> 
> 
> On Aug 17, 2018, at 12:16 PM, Richard Eisenberg 
> <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
> 
> 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<mailto: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<mailto:mail at joachim-breitner.de>
> http://www.joachim-breitner.de/
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C549984ffda524c614d6008d6045cf7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636701194744752293&sdata=i4KtV3B%2B2YUluqn3Rx7th3sm6%2BDYkinoMQE6n%2FNqdZQ%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-
> committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee