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`
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 polymorphi
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 impl
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 = f
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 definiti
