-XStrict: Why some binders are not made strict?

[Simon Peyton Jones]

In addition, making pattern matching strict in this way makes it hard to mix and match strict and lazy data types (e.g. Maybe), because using a lazy data type from another module will make it appear strict in your code (hurting modularity).

I didn’t understand that.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell
Sent: 11 December 2015 12:22
To: Roman Cheplyaka <roma at ro-che.info>
Cc: ghc-devs at haskell.org
Subject: Re: -XStrict: Why some binders are not made strict?

I believe Scala has optional lazy values, but you could also consider in strict languages if you do manual thunking.

If we force strictness all the way down it's not really call-by-value either, because the caller doesn't know what to evaluate (I think).

In addition, making pattern matching strict in this way makes it hard to mix and match strict and lazy data types (e.g. Maybe), because using a lazy data type from another module will make it appear strict in your code (hurting modularity).

On Fri, Dec 11, 2015 at 7:54 AM, Roman Cheplyaka <roma at ro-che.info<mailto:roma at ro-che.info>> wrote:
On 12/10/2015 04: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?

Well, strict languages do not have lazy data to force to begin with, do they?

Personally, I find the simple intuition of "all patterns are strict by default" rather appealing.

E.g. I wouldn't expect the expressions

  let (v1,v2) = a in f v2

and

  let (v1,v2) = a; v3 = v2 in f v3

to have different semantics.

If we decide to adopt this semantics, we need to address the meaning of the pattern

  ~(v1, v2)

under -XStrict. Intuitively, ~ should propagate to the subpatterns. An alternative is to disallow this pattern under -XStrict and require writing all ~s explicitly, which may get tedious:

  ~(~v1, ~v2)
  ~(~v1, ~(~v2, ~v3))
  etc.

We also need to ensure the consistency between this extension and the unlifted data types proposal [1], given their similarity. Interestingly, I don't see constructor patterns explained there either.

[1]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes



_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2faaa875c5764c6701d408d30225b68d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xaohOEQRieXHuSG%2btmcecSX%2fr7tQG1OMkt1YQe9kmT0%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/9c23631f/attachment.html>