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
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#Dynamicsemanticsofun...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs