Re: Strictness/laziness warnings

How would you detect the argument only being forced some of the time? Sounds like a lot of long-term cross-module book-keeping. -Edward On Sat, May 28, 2016 at 10:02 PM, David Feuer wrote: > I'm not suggesting these things are *wrong*, and I wouldn't want the > warnings

Re: Strictness/laziness warnings

I'm not suggesting these things are *wrong*, and I wouldn't want the warnings to be included in -Wall. They're just possible areas of concern. By "conditionally strict" I mean that the argument in question is only forced sometimes. On May 28, 2016 9:16 PM, "Edward Kmett" wrote:

Re: Strictness/laziness warnings

I have code that'd trip at least 2&3 in use in production. #2 arises for some tricks that Wren first introduced me to for loop invariant code motion. #3 arises when you want to memoize a result but only produce it lazily in case it isn't used. I don't quite understand what you mean by

Re: Unpacking single-field, single-strict-constructor GADTs and existentials

> Simon Peyton Jones microsoft.com> writes: > > Oh, that's helpful thank you. I have added comments! > I've added a further use case (Example 3 -- from my one-eyed focus on Records). And apologies if these are two dumb questions, but is there a bigger prize here? If we can figure out rules

Strictness/laziness warnings

There are certain patterns of strictness or laziness that signal the need for extra caution. I'm wondering whether it might be possible to offer warnings for different varieties of them, and pragmas suppressing the warnings at the relevant sites. Some function behaviors that suggest extra care:

comment lines in Cmm outputs

I'm reading a lot of Cmm these days and comments added by Cmm dump (which are apparently added after 8.0.1) are so annoying becuase they're not saying anything useful (what's the point of adding "// CmmCall" to a "call" line or "// CmmCondBranch" to a "if" line?) but making a lot of noise. Why

Re: can't build with release settings

Please ignore. I realized I had a bug in my code (which makes some changes in generated Cmm) and I realized -DDEBUG is not on for stage1 in release mode, so my assertions were not running. I have no idea how can the bug cause this error though... 2016-05-28 15:03 GMT-04:00 Ömer Sinan Ağacan

Re: can't build with release settings

I just had the same error when I checkout current HEAD. (without a distclean though) 2016-05-28 14:56 GMT-04:00 Ömer Sinan Ağacan : > Is anyone else having this problem when building with default settings > (no build.mk): > > "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf

can't build with release settings

Is anyone else having this problem when building with default settings (no build.mk): "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src