| > >I was thinking it would be nice if one could put a pragma on CAFs
that
| > >basically made ghc treat them as WHNF so it would float them inward
as
| > >far as possible including inside lambdas. in particular, constant
| > >strings that are created (cheaply) from efficient internal
| > >represe
On Wed, Oct 19, 2005 at 12:01:07AM +0200, Daan Leijen wrote:
> John Meacham wrote:
> >On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote:
> >>GHC tries not to create space leaks, but does not guarantee not to. In
> >>particular, the full laziness transformation is so beneficial mos
John Meacham wrote:
On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote:
GHC tries not to create space leaks, but does not guarantee not to. In
particular, the full laziness transformation is so beneficial most of
the time that, even though it can create a space leak GHC still do
On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote:
> GHC tries not to create space leaks, but does not guarantee not to. In
> particular, the full laziness transformation is so beneficial most of
> the time that, even though it can create a space leak GHC still does it
> (unless y
| Clearly, in this instance GHC is not transforming either of these
| definitions into the other. But are there other compile time
transformations
| performed by GHC that might result in more (excessive) sharing, in
| particular the creation of new common sub-expressions such as pxs? If
not,
| is t