> Why do you say
>
> | In our case, we prefer the result in 7.10.2 of course, because that's a
> | more precise demand and it gives us more opportunities for
> | optimizations. But I guess this could potentially reveal itself in some
>
> What optimisations do you have in mind?
I just had
| coreToStgExpr (Case scrut bndr ty [])
| = coreToStgExpr (Case scrut bndr ty [(DEFAULT, [], mkImpossibleExpr
| ty)])
Yes that should be fine.
I'm afraid I have no idea why you are getting
| Oops! Entered absent arg w_sc1l FilePath
or seg-faults.
Simon
|
| But that may be
> So feel free to make Lint cleverer; make sure you add a Note. But if it
> /needs/ to be cleverer, that suggests that the simplifier should be cleverer
> instead, and should simplify the code so that even a dumb Core Lint has no
> trouble.
Good point. The problem is linter is checking every
| I wanted to ask: Is there a restriction on what kind empty case
| expressions are supported by the code generator or can I just improve
| the lint check and assume that the code will be handled by the code
| generator correctly?
I believe the latter. See CoreToStg line 364.
So feel free
See Note [Add demands for strict constructors] in DmdAnal, esp the bit that says
If the argument is not used at all in the alternative (i.e. it is
Absent), then *don't* add a 'seqDmd'. If we do, it makes it look used
and hence it'll be passed to the worker when it doesn't
On 26 February 2016 at 02:09, Ben Gamari wrote:
>> Thank you for RC2.
> I'm happy to help.
I think you're doing a great job.
>> I finally built ghc-8.0.0 for Fedora Rawhide (quick build):
>> https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1
>> (perf build is still