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

But is this summary correct:

- @ denotes a type application if it is preceded by a non-identifier character and succeeded by a non-whitespace character - @ denotes an as-pattern if is preceded by an identifier character or succeeded by a whitespace character

This means that `f@ Int` is an as-pattern.

I still say this is an awkward twist, but I see what you're getting at. Richard

On Aug 20, 2018, at 9:05 AM, Simon Peyton Jones wrote:

I think the goal is to preserve the syntactic space for f ((f -> Just x) @ (g -> Just y)) = ... as an "and-pattern" which matches both patterns and binds both x and y. And also perhaps

f ((f -> Just x)@(g -> Just y)) = ...

by narrowing the situations in which "@" introduces a type argument to just <space>@<type>

with white space before, but not after the "@".

And do to his in both terms and patterns.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 19 August 2018 02:32 | To: Joachim Breitner | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Discussion about "Type | Application in Patterns" (#126) | | So what's the new rule? Is it: | | - @ denotes a type application if it is preceded by a non-identifier | character and succeeded by a non-whitespace character | - @ denotes an as-pattern if is preceded by an identifier character or | succeeded by a whitespace character | | This means that `f@ Int` is an as-pattern. | | I think the new rule just adds another twist to an already too- | complicated plot. | | I'm not worried about backward-compat issues here (echoing Joachim's | sentiments) but I don't see the advantage to this new spec. | | Richard | | > On Aug 17, 2018, at 1:27 PM, Joachim Breitner wrote: | > | > Hi, | > | > Am Freitag, den 17.08.2018, 13:00 -0400 schrieb 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. | > | > not opposed in principle, but if we go that route, it should also | > apply to type applications in expressions, for consistency. Are we | > willing to potentially break code out there? (Well, it’s an | > extension, the fix is simple and fully backward-compatible, and most | > people probably got it right in the first place, so maybe breaking is | > not too bad.) | > | > Cheers, | > Joachim | > | > | > -- | > Joachim Breitner | > mail@joachim-breitner.de | > | > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | > achim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca3c9 | > | e99884a34ec6670d08d605739f1f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C | > | 0%7C636702391484409758&sdata=mFolm%2BaXnNO%2FMdniUugnuqcotyGViJbtf | > qK%2FKD1VM0I%3D&reserved=0 | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committ | > ee | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee