Re: SIGPIPE in the GHC runtime

2010-08-18 Thread Brian Bloniarz
On 08/18/2010 07:06 PM, Donn Cave wrote: > Quoth Brian Bloniarz , > ... >> I just tested linux in this scenario, it gives EPIPE as I'd expect. >> Linux's SA_RESTART has been reliable in my limited experience. Do >> you have an OpenSolaris install to test by any chance? The code is >> below. > > No

Re: Possible bug with GADTs?

2010-08-18 Thread Dan Knapp
Wow, I didn't seriously expect it was a real bug. This is my first time finding a confirmed compiler bug. Thanks for the response! On Wed, Aug 18, 2010 at 2:49 AM, Simon Peyton-Jones wrote: > | {-# LANGUAGE GADTs #-} > | module Foo where > | > | data TemplateValue t where > |   TemplateList ::

Re: SIGPIPE in the GHC runtime

2010-08-18 Thread Donn Cave
Quoth Brian Bloniarz , ... > I just tested linux in this scenario, it gives EPIPE as I'd expect. > Linux's SA_RESTART has been reliable in my limited experience. Do > you have an OpenSolaris install to test by any chance? The code is > below. No, sorry! But I don't doubt that with the right compi

Re: SIGPIPE in the GHC runtime

2010-08-18 Thread Brian Bloniarz
On 08/18/2010 04:55 PM, Donn Cave wrote: > Quoth Brian Bloniarz , > >> IMHO the simplest fix is the patch below: simply >> avoid SIG_IGN, instead install a handler which does nothing. >> This way, an exec() restores the handler to SIG_DFL. I've >> included a testcase too. > > I don't know enough

Re: SIGPIPE in the GHC runtime

2010-08-18 Thread Donn Cave
Quoth Brian Bloniarz , > IMHO the simplest fix is the patch below: simply > avoid SIG_IGN, instead install a handler which does nothing. > This way, an exec() restores the handler to SIG_DFL. I've > included a testcase too. I don't know enough to make a case for or against this, but the side effe

Re: Surprising strictness properties of pre-order fold over a Data.Map

2010-08-18 Thread Johan Tibell
On Wed, Aug 18, 2010 at 4:38 PM, Lennart Augustsson < lennart.augusts...@gmail.com> wrote: > You don't know that f is strict in its first argument so you cannot > deduce that go is strict in z in the first case. > I'm not sure I understand. f :: Int -> Int -> Int -> Int f = \x y z -> x + y + z

Re: Surprising strictness properties of pre-order fold over a Data.Map

2010-08-18 Thread Johan Tibell
On Wed, Aug 18, 2010 at 2:47 PM, Ian Lynagh wrote: > On Wed, Aug 18, 2010 at 12:01:54PM +0200, Johan Tibell wrote: > > > > foldlWithKey' :: (b -> k -> a -> b) -> b -> Map k a -> b > > foldlWithKey' f z0 m = go z0 m > > where > > go z Tip = z > > go z (Bi

Re: Surprising strictness properties of pre-order fold over a Data.Map

2010-08-18 Thread Ian Lynagh
On Wed, Aug 18, 2010 at 12:01:54PM +0200, Johan Tibell wrote: > > foldlWithKey' :: (b -> k -> a -> b) -> b -> Map k a -> b > foldlWithKey' f z0 m = go z0 m > where > go z Tip = z > go z (Bin _ kx x l r) = let x' = f (go z l) kx x in x' `seq` go x' r > > C

Re: Possible bug with GADTs?

2010-08-18 Thread Andrea Vezzosi
On Tue, Aug 17, 2010 at 8:54 PM, Dan Knapp wrote: > Below, please find a snippet from a program I'm working on, and the > error it produces.  I was told in #haskell that this was "pretty > suspect" and could conceivably be a ghc bug.  So I'm reporting it > here.  I'd also be grateful for workaroun

Surprising strictness properties of pre-order fold over a Data.Map

2010-08-18 Thread Johan Tibell
Hi, I was adding a strict pre-order fold to the Data.Map module and I ran into this slightly surprising behavior. Modeled on foldl' for lists I defined foldlWithKey' :: (b -> k -> a -> b) -> b -> Map k a -> b foldlWithKey' f z0 m = go z0 m where go z Tip = z