Hi Carter, We are using let !(#x,y#) = … actually. Having the strict behaviour is not particularly difficult. You can even use case … of (#x, y#) ->… directly, it’s not too bad. My complaint, as it were, is solely about the potential for mistakes.
On Fri, Aug 28, 2020 at 3:20 PM Carter Schonwald <carter.schonw...@gmail.com> wrote: > Have you tried using do notation for bindings you want to keep strict, > with Eg the identity monad? That doesn’t address the design critique but > gives you a path forward ? > > I do agree that the semantics / default recursivity Of let bindings can > be inappropriate for non recursive code , but would any other non uniform > semantics or optimization be safe? > > On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud <arnaud.spiw...@tweag.io> > wrote: > >> Dear all, >> >> >> I discovered the hard way, yesterday, that lazy let pattern >> matching is allowed on unboxed tuples. And that it implicitly reboxes >> the pattern. >> >> >> Here is how the manual describes it, from the relevant section >> <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-UnboxedTuples> >> : >> >> >> >> >> You can have an unboxed tuple in a pattern binding, thus >> >> >> f x = let (# p,q #) = h x in ..body.. >> >> >> >> If the types of p and q are not unboxed, the resulting binding is lazy >> like any other Haskell pattern binding. The above example desugars like >> this: >> >> >> f x = let t = case h x of { (# p,q #) -> (p,q) } >> >> p = fst t >> >> q = snd t >> >> in ..body.. >> >> >> >> Indeed, the bindings can even be recursive. >> >> >> >> >> Notice how h x is lazily bound, hence won’t necessarily be run when >> body is forced. as opposed to if I had written, for instance, >> >> >> let u = hx >> >> in ..body.. >> >> >> >> My question is: are we happy with this? I did find this extremely >> surprising. If I’m using unboxed tuples, it’s because I want to >> guarantee to myself a strict, unboxed behaviour. But a very subtle >> syntactic detail seems to break this expectation for me. My >> expectation would be that I would need to explicitly rebox things >> before they get lazy again. >> >> >> I find that this behaviour invites trouble. But you may disagree. Let >> me know! >> >> >> >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs@haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs