-XStrict: Why some binders are not made strict?

[Johan Tibell]

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> 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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/20e45850/attachment.html>