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 Tue, 2007-05-01 at 09:50 -0700, Iavor Diatchki wrote: > Hello, > > On 5/1/07, Duncan Coutts <[EMAIL PROTECTED]> wrote: > > 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: > > This declaration uses existential and not universal quantification. > More concretely, there exists some type that classifies the state of > the stream but the users of the stream do not know what it is (by the > way I saw Don talk about this stream stuff and I think that it is > quite cool!). A polymorphic field is one where the ``forall`` is > associated with the field (it comes after the constructor), it allows > you to store polymorphic values in a datatype. Ah ok. When you said "strictness annotations on polymorphic fields" I assumed you meant just ordinary things like: data A a = A !a rather than local universal quantification. Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Polymorphic strict fields
Hello, On 5/1/07, Duncan Coutts <[EMAIL PROTECTED]> wrote: 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: This declaration uses existential and not universal quantification. More concretely, there exists some type that classifies the state of the stream but the users of the stream do not know what it is (by the way I saw Don talk about this stream stuff and I think that it is quite cool!). A polymorphic field is one where the ``forall`` is associated with the field (it comes after the constructor), it allows you to store polymorphic values in a datatype. Here is an example: data T = T (forall a. a -> a) make = T id use (T f) = (f True, f 'a') Hope this helps -Iavor ___ 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
Polymorphic strict fields
Hello, At present, the Haskell report specifies the semantics of strict datatype fields (the ones marked with !) in terms of the strict application operator $! [Section 4.2.1, paragraph "Strictness flags"]. However, if we were to add polymorphic fields to Haskell, then we cannot use this definition anymore because the application operator (or ``seq`` for that matter) does not have the correct type---we would need many rank-2 versions, one for each possible type scheme. 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. Hugs does not support strictness annotations on polymorphic fields (I thought that this was a bug but, perhaps, it was a delibarate choice?) It seems that even without overloading, we may think of polymorphic values as being parameterized by their type arguments, so that they are always in head-normal form. All of this leads me to think that perhaps we should not allow strictness annotations on polymorphic fields. Would people find this too restrictive? If so, does anoyone have ideas about what should happen and how to specify the behavior? -Iavor ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
