-XStrict: Why some binders are not made strict?

Thu Dec 10 16:18:51 UTC 2015

When implementing I took this:

> Notice that we do not put bangs on nested patterns. For example  let
> (p,q) = if flob then (undefined, undefined) else (True, False)   in
> ... will behave like  let !(p,q) = if flob then (undefined, undefined)
> else (True, False)  in ...

(from the spec) and applied it to all bindings, but I don't know if this
is the best implementation.

Cheers, Adam

On Thu, 10 Dec 2015, at 03:34 PM, Johan Tibell wrote:
> I'm snowed under but I promise I will try to reply soon! To think
> about in the mean time: what do existing strict languages with pattern
> matching do?
>
> On Tue, Dec 8, 2015 at 3:42 PM, Simon Peyton Jones
> <simonpj at microsoft.com> wrote:
>> Adam, Johan,
>>
>>
Looking at the user manual
>> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-haskell,
>>
and indeed the wiki page
>> https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
>>
it's not really clear whether the sub-components of a pattern are
strict.  That is, is the second equation of zip strict in x, and xs?
(Supposing for now that the list data structure is lazy).  The manual
doesn't say one way or the other.
>>
>>
What's the answer?  And could the user manual please say?
>>
>>
Thanks
>>
>>
Simon
>>
>>
| -----Original Message-----
>>
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer
>>
| Sinan Agacan
>>
| Sent: 08 December 2015 01:41
>>
| To: ghc-devs <ghc-devs at haskell.org>
>>
| Subject: -XStrict: Why some binders are not made strict?
>>
|
>>
| Let's say I have this code:
>>
|
>>
|zip :: [a] -> [b] -> [(a, b)]
>>
|zip [] [] = []
>>
|zip (x : xs) (y : ys) = (x, y) : zip xs ys
>>
|
>>
| With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm
| wondering
>>
| about
>>
| the motivation behind this, I found this interesting. I always
| thought -
>>
| XStrict
>>
| gives me this guarantee: If I'm using an already-defined
| variable(bound by
>>
| a
>>
| let or pattern matching) in an expression, I can be sure that the
| variable
>>
| won't be bottom in that expression, because it would be `seq`d
| before the
>>
| expression is evaluated.
>>
|
>>
| So if I have
>>
|
>>
|case ... of
>>
|D x y -> <body>
>>
|
>>
| or
>>
|
>>
|let x = ...
>>
|y = ...
>>
|in <body>
>>
|
>>
| In both cases I was thinking that in <body> 'x' and 'y' can't be
>>
| bottom(with
>>
| -XStrict). This would make -XStrict programs evaluate like they
| would in a
>>
| call-by-value language(even though in the RTS level thunks will
| be built).
>>
| Variables can't range over computations; all binders evaluated
| strictly
>>
| etc.
>>
|
>>
| Can anyone tell me about the motivation behind this decision?
>>
|
>>
| I think the wiki page actually conflicts with itself. It says "...
>>
| bindings to be
>>
| strict by default" but then in "case expressions" sections says
>>
|
>>
|case x of (a,b) -> rhs
>>
|
>>
|is interpreted as
>>
|
>>
|case x of !(a,b) -> rhs
>>
|
>>
| Here bindings 'a' and 'b' are not made strict. I'd expect
| something like:
>>
|
>>
|case x of (!a,!b) -> rhs
>>
|
>>
| (Which seems to be invalid Haskell, but same effect could be
| achieved with
>>
| `seq
>>
| a (seq b rhs)`)
>>
|
>>
| Thanks..
>>
|
>>
| (I also realized that the wiki page doesn't mention bindings in
| do syntax,
>>
| is
>>
| it because this case is implied by "function definitions"? That
| is, bangs
>>
| are
>>
| added after do syntax is desugared and so they become strict?)
>>
| _______________________________________________
>>
| ghc-devs mailing list
>>
| ghc-devs at haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
>>
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbc68c0830f5-
| 74466efd
>>
| 308d2ff70aba9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=c2VBbt%-
| 2f%2fR2c
>>
| yFecGEuQotO%2bV71VSbpmWnZJyV9d8KRk%3d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/88c8da60/attachment.html>