twhitehead:
> On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote:
> > On 16/10/2008, at 21:34, Simon Peyton-Jones wrote:
> > > BUT people who care probably UNPACK their strict fields too, which
> > > is even better. The time you can't do that is for sum types
> > >data T = MkT !
On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote:
> On 16/10/2008, at 21:34, Simon Peyton-Jones wrote:
> > BUT people who care probably UNPACK their strict fields too, which
> > is even better. The time you can't do that is for sum types
> >data T = MkT ![Int]
>
> You also can
| > BUT people who care probably UNPACK their strict fields too, which
| > is even better. The time you can't do that is for sum types
| >data T = MkT ![Int]
|
| You also can't do it for polymorphic components. I've used code like:
|
|data T a = MkT !a
|
|foo :: T (a,b) -> a
|f
On 16/10/2008, at 21:34, Simon Peyton-Jones wrote:
For strict *constructors*, on the other hand, we *do* guarantee to
evaluate the argument before building the constructor. We generate
a wrapper thus
wC = \ab. case a of { a' -> C a' b }
(Remember 'case' always evaluates in Core.) So
| I totally agree. Getting the value of the field should just evaluate
| x and then use a pointer indirection; there should be no conditional
| jumps involved in getting the value.
| GHC is just doing the wrong thing.
You're right. As Simon says, GHC's Core language has no type distinction
betw
Lennart Augustsson wrote:
True, if there can be indirections then that's bad news.
That would make strict fields much less efficient.
But I don't see why indirections should be needed. Simon?
This kind of thing has always been a problem for GHC, and IIRC hbc does/did
better here.
I don't kn
Bryan O'Sullivan wrote:
On Mon, Oct 13, 2008 at 1:58 AM, Simon Marlow <[EMAIL PROTECTED]> wrote:
Thanks! New versions of Alex & Happy uploaded.
Where to? I only see 2.3 on Hackage, and haskell.org claims that Alex
is still at 2.2.
Just on Hackage for the time being, I'll update the web pag
