You are my hero.
On Thu, Sep 3, 2020 at 9:22 AM Sebastian Graf wrote:
> Hi folks,
>
> I implemented what I had in mind in
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3959. CI should turn
> green any hour now, so feel free to play with it if you want to.
> With the wonderful
> 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
wonderful!
On Thu, Sep 3, 2020 at 12:22 PM Sebastian Graf wrote:
> Hi folks,
>
> I implemented what I had in mind in
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3959. CI should turn
> green any hour now, so feel free to play with it if you want to.
> With the wonderful
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
> 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
>
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
> 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
Hi folks,
I implemented what I had in mind in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3959. CI should turn
green any hour now, so feel free to play with it if you want to.
With the wonderful https://github.com/mpickering/ghc-artefact-nix it will
just be `ghc-head-from 3959`.
Cheers,
>
> 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:
11 matches
Mail list logo
