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:[email protected]] On Behalf Of Johan Tibell Sent: 11 December 2015 12:22 To: Roman Cheplyaka <[email protected]> Cc: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
