Bang patterns

[Ben Millwood]

On Fri, Feb 01, 2013 at 05:10:42PM +0000, Ian Lynagh wrote:
>
>The first is suggested by "A bang only really has an effect if it
>precedes a variable or wild-card pattern" on
>http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
>
>We could therefore alter the lexical syntax to make strict things into
>lexems, for example
>    reservedid -> ...
>                | _
>                | !_
>    strictvarid -> ! varid
>etc. This would mean that "f !x" is 2 lexemes, and "f ! x" 3 lexemes,
>with the former defining the function 'f' and the latter defining the
>operator '!'.
>
>This has 3 downsides:
>
>* It would require also accepting the more radical proposal of making
>  let strict, as it would no longer be possible to write
>    let ![x,y] = undefined in ()

We really can't make let strict, in my view: its laziness is sort of 
fundamental. I don't see why the given example necessitates it though: 
just use case-of in that scenario. In fact, I've kind of always been 
uncomfortable with bang patterns in let-statements. I feel like I should 
be able to omit an unused let-binding without affecting my program at 
all, and bang patterns in let make that no longer true.

>* It would mean that "f !x" and "f !(x)" are different. Probably not a
>  big issue in practice.

Yeah, I'm not upset about this. We'd be thinking of the ! as a decorator 
in the same way that, say, infix-backticks are: we don't expect `(foo)` 
to work.

>* It may interact badly with other future extensions. For example,
>    {-# LANGUAGE ViewPatterns #-}
>    f !(view -> x) = ()
>  should arguably be strict in x.
>  (you might also argue that it should define the operator '!'.
>  Currently, in ghc, it defines an 'f' that is lazy in x, which IMO is a
>  bug).

Hmm. Not quite strict in x. I'd think the right way to make that strict 
in x is:

      f (view -> !x) = ()

What you want is possibly to evaluate the thing you pass to the view 
/before/ matching on the result. But I imagine that in most cases your 
view function will be strict so the difference will be immaterial.

I agree that GHC current behaviour looks like a bug.

>The second is to parse '!' differently depending on whether or not it is
>followed by a space. In the absence of a decision to require infix
>operators to be surrounded by spaces, I think this is a bad idea: Tricky
>to specify, and to understand.

Hmm. It's a shame because in real code operator definitions are almost 
invariably surrounded by spaces, even when the use of the operator 
wouldn't be. But I agree in general.

>The third is to parse '!' in patterns in the same way that '~' is parsed
>in patterns, except that (!) would be accepted as binding the operator
>'!'. This means that "f ! x" defines f.

This is roughly how it's done at present, right? It's annoyingly 
inconsistent, but fairly low-impact.

>So my proposal would be to go with option 3. What do you think? And did
>I miss any better options?

You missed the option of going the way of ~ and making ! an illegal name 
for an operator. Obvious drawbacks, probably not a good idea, but it 
would be the most consistent solution, so I wouldn't dismiss it 
immediately.

(If we do come up with a way that doesn't involve making ! illegal, 
maybe we should consider allowing ~ as an operator as well!)

There's another alternative entirely, that I haven't really thought 
about: introduce bang patterns on types instead of on variables. I 
realise this is less flexible, but! it covers many common cases, it 
avoids the infix confusion altogether, it echoes the existing usage for 
strict datatypes, and it makes the strictness of a function 
(potentially) part of its type signature, which would be handy in 
documentation. I realise this is a bit late in the game to be including 
this option, but if it doesn't get thought about now, it never will.

Anyway, in light of my above comments, I think I like the first option 
the best (so bang patterns only apply to variables, let doesn't become 
strict).

regards,
Ben