On Tue, Feb 26, 2013 at 10:00:32AM -, o...@okmij.org wrote:
> Tom Ellis wrote:
> > To avoid retaining a large lazy data structure in memory it is useful to
> > hide it behind a function call. Below, "many" is used twice. It is hidden
> > behind a function call so it can be garbage collected b
Tom Ellis wrote:
> To avoid retaining a large lazy data structure in memory it is useful to
> hide it behind a function call. Below, "many" is used twice. It is hidden
> behind a function call so it can be garbage collected between uses.
As you discovered, it is quite challenging to ``go again
Hi,
Am Sonntag, den 24.02.2013, 18:41 + schrieb Tom Ellis:
> On Sun, Feb 24, 2013 at 07:12:24PM +0100, Joachim Breitner wrote:
> > You should try:
> >
> > > million :: () -> Int
> > > million _ = 10 ^ (6 :: Int)
> > >
> > > many :: () -> [Int]
> > > many x = [1..million x]
>
> Thanks Joachim
On Sun, Feb 24, 2013 at 06:25:56PM +, Don Stewart wrote:
> If you explicitly rely on this not happening, turn it off:
>
> $ ghc -O2 -fno-full-laziness --make A.hs -rtsopts -fforce-recomp
> [1 of 1] Compiling Main ( A.hs, A.o )
> Linking A ...
>
> $ time ./A +RTS -M750k
> (5050
On Sun, Feb 24, 2013 at 07:12:24PM +0100, Joachim Breitner wrote:
> You should try:
>
> > million :: () -> Int
> > million _ = 10 ^ (6 :: Int)
> >
> > many :: () -> [Int]
> > many x = [1..million x]
Thanks Joachim, but that doesn't work either.
Tom
% cat thunkfail.hs
{-# OPTIONS_GHC -fno-warn
In toy examples like this it will be generally hard to convince GHC not to
just collapse your program down to a constant, when you're turning up the
optimization level.
In particular, you are implying -ffull-laziness with -O (or -O2), which can
increase sharing.
> GHC doesn't implement complete f
Hi,
I believe, without checking, that
Am Sonntag, den 24.02.2013, 17:49 + schrieb Tom Ellis:
> many :: () -> [Int]
> many () = [1..million]
is indeed called many times. The problem is that [1..million] is not
dependent on the parameter, so GHC will float it out to a top level
declaration, an
To avoid retaining a large lazy data structure in memory it is useful to
hide it behind a function call. Below, "many" is used twice. It is hidden
behind a function call so it can be garbage collected between uses. That's
good. When compiling with "-O" it seems that GHC 7.4.1 decides to keep it
Bernie Pope writes:
> You can use side effects to observe the order of evaluation, by
> wrapping observed expressions (thunks) with some IO computation inside
> unsafePerformIO.
Not what OP asks for, but I've used a variant of this as a rather
hackish to provide progress reporting. I take a lis
On 15 October 2010 07:53, Mihai Maruseac wrote:
> Hi,
>
> Is there a way to determine the order in which thunks are created and
> expanded/evaluated in Haskell (GHC)? I'm looking mainly at some
> existing interface but if there is only something in the GHC source it
> will suffice.
You can use si
On Fri, Oct 15, 2010 at 1:19 AM, Jason Dagit wrote:
>
>
> On Thu, Oct 14, 2010 at 2:52 PM, Evan Laforge wrote:
>>
>> > I don't know of any way to examine this for a running program. You can
>> > get
>> > GHC to spit out core and STG using -ddump-core and -ddump-stg flags:
>>
>> There's no -ddump
On Thu, Oct 14, 2010 at 2:52 PM, Evan Laforge wrote:
> > I don't know of any way to examine this for a running program. You can
> get
> > GHC to spit out core and STG using -ddump-core and -ddump-stg flags:
>
> There's no -ddump-core flag. I was puzzled about the proper way to
> get "final" cor
> I don't know of any way to examine this for a running program. You can get
> GHC to spit out core and STG using -ddump-core and -ddump-stg flags:
There's no -ddump-core flag. I was puzzled about the proper way to
get "final" core, and have been using -ddump-simpl, but I don't know
if that's co
On Thu, Oct 14, 2010 at 1:53 PM, Mihai Maruseac wrote:
> Hi,
>
> Is there a way to determine the order in which thunks are created and
> expanded/evaluated in Haskell (GHC)? I'm looking mainly at some
> existing interface but if there is only something in the GHC source it
> will suffice.
>
You'l
Hi,
Is there a way to determine the order in which thunks are created and
expanded/evaluated in Haskell (GHC)? I'm looking mainly at some
existing interface but if there is only something in the GHC source it
will suffice.
Thanks,
--
Mihai
___
Haskell
15 matches
Mail list logo
