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

Simon Peyton Jones simonpj at microsoft.com
Mon Aug 20 13:05:30 UTC 2018


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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Richard Eisenberg
|  Sent: 19 August 2018 02:32
|  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)
|  
|  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 <mail at joachim-
|  breitner.de> 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 at 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 at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committ
|  > ee
|  
|  _______________________________________________
|  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