Re: Polymorphic strict fields
Iavor Diatchki wrote: Notice, furthermore, that the behavior of such constructors may be a bit unexpected when combined with overloading. Consider, for example, the following declarations: data T = T !(forall a. Eq a = a) test = seq (T undefined) True In GHC 6.6 ``test`` evaluets to ``True`` because ``undefined`` is converted to a function that expects its implict evidence argument. It's the same with functions: myseq :: (forall a. Eq a = a) - b - b myseq = seq myseq undefined True == True -- Ashley Yakeley ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Polymorphic strict fields
On Mon, 2007-04-30 at 19:47 -0700, Iavor Diatchki wrote: All of this leads me to think that perhaps we should not allow strictness annotations on polymorphic fields. Would people find this too restrictive? Yes. Our current implementation of stream fusion relies on this: data Stream a = forall s. Unlifted s = Stream !(s - Step a s) -- ^ a stepper function !s-- ^ an initial state We use strictness on polymorphic (class constrained) fields to simulate unlifted types. We pretend that the stream state types are all unlifted and have various strict/unlifted type constructors: data (Unlifted a, Unlifted b) = a :!: b = !a :!: !b instance (Unlifted a, Unlifted b) = Unlifted (a :!: b) where ... Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
