<div dir="ltr">I believe Scala has optional lazy values, but you could also consider in strict languages if you do manual thunking.<div><br></div><div>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).</div><div><br></div><div>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).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 7:54 AM, Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/10/2015 04:34 PM, Johan Tibell wrote:<br>
> I'm snowed under but I promise I will try to reply soon! To think about<br>
> in the mean time: what do existing strict languages with pattern<br>
> matching do?<br>
<br>
</span>Well, strict languages do not have lazy data to force to begin with, do they?<br>
<br>
Personally, I find the simple intuition of "all patterns are strict by default" rather appealing.<br>
<br>
E.g. I wouldn't expect the expressions<br>
<br>
  let (v1,v2) = a in f v2<br>
<br>
and<br>
<br>
  let (v1,v2) = a; v3 = v2 in f v3<br>
<br>
to have different semantics.<br>
<br>
If we decide to adopt this semantics, we need to address the meaning of the pattern<br>
<br>
  ~(v1, v2)<br>
<br>
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:<br>
<br>
  ~(~v1, ~v2)<br>
  ~(~v1, ~(~v2, ~v3))<br>
  etc.<br>
<br>
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.<br>
<br>
[1]: <a href="https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes</a><br>
<br>
<br>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>