I am not sure what you'd expect this to do, but under what I was suggesting
it would be equivalent to
`let ~(x,y) = undefined in x `seq` y `seq ()`
Obviously it would be nice to warn/report error that this is probably a
mistake, which seems pretty easy to do.
What useful functionality do you think
I agree that the strictness there was surprising, but I think this may be a
case where what is superficially expected is, in the end, inconsistent.
What about:
let ~(!x, !y) = undefined in ()
If nested bang patterns implied strictness of their parents, this valid
expression seems not to make any
Ah, yes, quite right: since the projections match the whole patterns, the
bang patterns in a constructor would be forced as soon as one of the fields
in the constructor is used, so this also diverges:
ex3 = let (x, !y) = (5,undefined) in x
The rule is consistent, to me it just seems quite unintui
This whole area is clearly somewhat troublesome:
> On Sep 10, 2020, at 12:05 PM, Iavor Diatchki wrote:
>
> 3. nested bang patterns in pattern bindings should count as "uses" of the
> value and therefore should be strict. For example if I write `let ( !x, !y )
> = undefined in ()`, I think thi
- (1) is *necessary*.
>>- (2) is strictly stronger, and will make fewer program defined. But
>>is perhaps less surprising.
>>
>>
>>
>> I think you could make a proposal out of that if you wanted. I can’t
>> decide if I like it, myself, but I th
Diatchki
> *Sent:* 07 September 2020 20:46
> *To:* Simon Peyton Jones
> *Cc:* Richard Eisenberg ; Spiwack, Arnaud <
> arnaud.spiw...@tweag.io>; GHC developers
> *Subject:* Re: !RE: Implicit reboxing of unboxed tuple in let-patterns
>
>
>
>
>
>
>
> On
: Re: !RE: Implicit reboxing of unboxed tuple in let-patterns
On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs
mailto:ghc-devs@haskell.org>> wrote:
1. I don’t understand the details of Iavor’s proposal to add that “unlifted
patterns are strict”, in addition to (1). Do yo
>
>
> *From:* ghc-devs *On Behalf Of *Richard
> Eisenberg
> *Sent:* 02 September 2020 14:47
> *To:* Spiwack, Arnaud
> *Cc:* GHC developers
> *Subject:* Re: Implicit reboxing of unboxed tuple in let-patterns
>
>
>
>
>
>
>
> On Sep 2, 2020, at 9:3
l a constructor of
an unlifted data type), suggesting to add a “!” or a “~” to make the intent
clear.
Simon
From: ghc-devs On Behalf Of Richard Eisenberg
Sent: 02 September 2020 14:47
To: Spiwack, Arnaud
Cc: GHC developers
Subject: Re: Implicit reboxing of unboxed tuple in let-patterns
On Fri, Sep 4, 2020 at 5:47 PM Iavor Diatchki
wrote:
Yes
>
Interesting. Thanks.
Personally, I don’t really know how to resolve the tension between the
outer pattern saying: I *really* want to be lazy; and uniformity with the
unlifted-variable-binding case.
The point about b
b = let ~(MkX z) =
> I guess a more explicit option would be to make it an error to use a lazy
pattern on an unlifted type, and require programmers to manually add the
`!` but I am not sure that gains much, and is more work in the compiler.
Not being used to deal with unlifted types, this would be my preferred
optio
Yeah, I think these are nice examples that illustrate some of the
problems with the current behavior of GHC. For example, I think it is
weird that `b` non-terminates, but `c` does, because `z` is not used. I
would expect those to be equivalent.
My preference would be to use the simple rule I me
> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki wrote:
>
> How about the following rule: unlifted patterns are always strict (i.e., you
> desugar them as if they had an explicit `!`). A pattern is "unlifted" if
> the type it examines is unlifted. Seems simple enough and, I think, it
> wou
How about the following rule: unlifted patterns are always strict (i.e.,
you desugar them as if they had an explicit `!`). A pattern is
"unlifted" if the type it examines is unlifted. Seems simple enough and,
I think, it would do what most folks would expect.
I guess a more explicit option w
> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud wrote:
>
> This is all a tad tricky, I must say.
... which is one of the reasons I originally wanted one simple rule. I'm not
now saying I was in the right, but it is an attractive resting point for this
discussion.
To be clear, I don't think t
>
> Right now, there is one rule: if the type of any variable bound in the
>> pattern is unlifted, then the pattern is an unlifter-var pattern and is
>> strict.
>>
>
> I think the intuition I followed so far was "bindings with unlifted *RHS*
> are strict".
>
This is a very different rule indeed!
Hi,
Right now, there is one rule: if the type of any variable bound in the
> pattern is unlifted, then the pattern is an unlifter-var pattern and is
> strict.
>
I think the intuition I followed so far was "bindings with unlifted *RHS*
are strict".
So if I take a program in a strict language with
>
> This thread is suggesting to add a special case -- one that seems to match
> intuition, but it's still a special case. And my question is: should the
> special case be for unboxed tuples? or should the special case be for any
> pattern whose overall type is unlifted?
>
My intuition would be: f
> On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud wrote:
>
> Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know
> what the semantics of these ought to be. It does look like an interesting can
> of worms. How do they currently desugar?
Right now, there is one rule: if the t
> I admit I don't feel as strongly any more. My argument in that thread was
> from the standpoint of a language designer: there is really no reason, a
> priori, for an unboxed-tuple binding to be strict. What controls strictness
> is whether the bound variables are of unlifted type. However, I'm cu
> On Aug 31, 2020, at 10:34 AM, Spiwack, Arnaud wrote:
>
> That being said, Richard seemed to feel rather strongly about this one.
> Richard, do you still agree with your then position that let (#x, y#) = …
> being a lazy pattern (hence implicitly boxes the pair) is the right semantics?
I ad
I haven't used unboxed tuples enough to perhaps feel the pain, but on
paper the current design makes sense to me. The laziness of the binding
is suppose to have to do with the runtime rep of the binding itself, not
any enclosing pattern.
For example take
{-# LANGUAGE ScopedTypeVariables #
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
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
24 matches
Mail list logo
