Hi, I'm a bit puzzled by this observatio that I made. I have a function that, pseudocoded, lookes somewhat like f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) where ins i = manipulates the first element of the list Now, without the ins'es, the function appears to be lazy, i.e I can "take" a part of it without evalutating the rest. With the ins'es, the whole thing seems to be calculated as soon as I touch it. Is this obvious? Or is my observation wrong? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
On 18 Feb 2002, Ketil Z. Malde wrote:
Hi,
I'm a bit puzzled by this observatio that I made. I have a function that, pseudocoded, lookes somewhat like
f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) where ins i = manipulates the first element of the list
Now, without the ins'es, the function appears to be lazy, i.e I can "take" a part of it without evalutating the rest. With the ins'es, the whole thing seems to be calculated as soon as I touch it.
Is this obvious? Or is my observation wrong?
-kzm
um, looks like ins i returns a function of one argument which results in a list. (or ins is a function of two arguments which results in a list and ins i is just using currying; however you want to look at it) My question is if that function (ins i) is strict. Jay
On Mon, 18 Feb 2002, Jay Cox wrote:
On 18 Feb 2002, Ketil Z. Malde wrote:
Hi,
I'm a bit puzzled by this observatio that I made. I have a function that, pseudocoded, lookes somewhat like
f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) where ins i = manipulates the first element of the list
Now, without the ins'es, the function appears to be lazy, i.e I can "take" a part of it without evalutating the rest. With the ins'es, the whole thing seems to be calculated as soon as I touch it.
Is this obvious? Or is my observation wrong?
-kzm
um, looks like ins i returns a function of one argument which results in a list. (or ins is a function of two arguments which results in a list and ins i is just using currying; however you want to look at it)
My question is if that function (ins i) is strict.
Jay
<Cough>. I should have read your letter more closely.
where ins i = manipulates the first element of the list
if you mean that (ins i) :: [a] -> [a] manipulates the first element of
the list it takes then of course it is strict. because in
ins i = \x -> case x of
(a:as) -> foo a : as
[] -> []
where foo a = ...
((ins i) list) must pattern match on list. therefore (ins i) _|_ = _|_
QED.
I guess the kind of strictness I was thinking about is something along
the lines of what you might get if you applied deepseq to the list (if
such a type of strictness has been defined by anybody!)
I got a bit confused.
(example definition for sake of argument)
(a:xs) ++ list = a:(xs ++ list)
[] ++ list = list
If (ins i) had such deep strictness then when the first element of (f i as
bs cs) was forced, haskell would generate all of the list created by
(ins i (f (i+1) as) since (++) is strict in the first argument.
however, (:) is strict in neither argument, so (++) is lazily applied.
Anyway...
You might follow Bernard James POPE
Jay Cox
where ins i = manipulates the first element of the list
if you mean that (ins i) :: [a] -> [a] manipulates the first element of the list it takes then of course it is strict. because in
It is strict in the head of the list, yes. I.e. it is defined as ...where ins i ((_,x):xs) = (i,x):xs Apologies for being unprecise.
PS: deepseq was mentioned earlier in either this list or the other main Haskell list. I believe it was actually a DeepSeq module of some sort.
After some heap profiling (which produces marvellous plots, but is very expensive in running time. My tests that normally (without profiling, or just -p) run in a couple of minutes took over an hour. Also, the graphs indicate quite a bit less than top, but I ascribe that to the RTS and garbage-collectables lying around), I'm starting to suspect I'm generating a lot of unevaluated thunks. Is there any good tutorial or other material dealing with, and improving (memory) performance by, strictness in Haskell? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (2)
-
Jay Cox -
ketil＠ii.uib.no