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@haskell.org] On Behalf Of Johan Tibell
Sent: 11 December 2015 12:22
To: Roman Cheplyaka
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#Dynamicsemanticsofun... _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devshttps://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