* Kyle Hanson hanoo...@gmail.com [2013-08-20 18:23:48-0700]
So I am not entirely clear on how to optimize for performance for lazy
bytestrings.
Currently I have a (Lazy) Map that contains large BSON values (more than
1mb when serialized each). I can serialize BSON documents to Lazy
of bytestings so I have another Map
object that has the serialized bytestrings that I populate it with every
time the original BSON Map changes. Should the map be strict or lazy?
Should the bytestrings it stores be strict or lazy?
Any help in understanding laziness would be appreciated.
--
Kyle Hanson
On 12 Sep 2012, at 16:04, Eric Velten de Melo wrote:
The behaviour I want to achieve is like this: I want the program when
compiled to read from a file, parsing the PGM and at the same time
apply transformations to the entries as they are read and write them
back to another PGM file.
Such
Subject: Re: [Haskell-cafe] Either Monad and Laziness
On 9/14/12 5:16 PM, Eric Velten de Melo wrote:
But now I'm kinda lost. Is there an easy way to explain the difference
between:
-iteratee
-conduit
-enumerator
I tend to group them into three families. 'iteratee' and 'enumerator
On 9/14/12 5:16 PM, Eric Velten de Melo wrote:
But now I'm kinda lost. Is there an easy way to explain the difference between:
-iteratee
-conduit
-enumerator
John Lato's iteratee library is the original one based on Oleg
Kiselyov's work. I've used it a fair deal and am quite fond of it.
On 13 September 2012 20:29, wren ng thornton w...@freegeek.org wrote:
On 9/12/12 5:37 PM, Francesco Mazzoli wrote:
At Wed, 12 Sep 2012 12:04:31 -0300,
Eric Velten de Melo wrote:
It would be really awesome, though, if it were possible to use a
parser written in Parsec with this, in the
On 9/12/12 5:37 PM, Francesco Mazzoli wrote:
At Wed, 12 Sep 2012 12:04:31 -0300,
Eric Velten de Melo wrote:
It would be really awesome, though, if it were possible to use a
parser written in Parsec with this, in the spirit of avoiding code
rewriting and enhancing expressivity and abstraction.
I am currently trying to rewrite the Graphics.Pgm library from hackage
to parse the PGM to a lazy array.
Laziness and IO really do not mix.
The problem is that even using a lazy array structure, because the
parser returns an Either structure it is only possible to know if the
parser
array.
Laziness and IO really do not mix.
The problem is that even using a lazy array structure, because the
parser returns an Either structure it is only possible to know if the
parser was successful or not after the whole file is read,
That is one of the problems. Unexpected memory blowups
to rewrite the Graphics.Pgm library from hackage
to parse the PGM to a lazy array.
Laziness and IO really do not mix.
The problem is that even using a lazy array structure, because the
parser returns an Either structure it is only possible to know if the
parser was successful or not after
At Wed, 12 Sep 2012 12:04:31 -0300,
Eric Velten de Melo wrote:
It would be really awesome, though, if it were possible to use a
parser written in Parsec with this, in the spirit of avoiding code
rewriting and enhancing expressivity and abstraction.
There is
the whole file is read, therefore
requiring it to read the entire file before applying the
transformations, ruining the property of laziness.
Is there some way to keep this from happening? Should I even want to
make it like this? Not really a real life situation, but imagine I
want to read a really
On Tue, Sep 11, 2012 at 9:36 AM, Eric Velten de Melo
ericvm...@gmail.com wrote:
Any thoughts? Hopefully I'm not saying anything really stupid.
You can intersperse decoding errors in the output, e.g. output is
[Either Error DecodedChunk]. Then all the processors have to deal
with it, but if you
Use a tuple: (Result,Maybe Error) rather than an Either. Do everything
lazily, and in the case of an error, undo the result.
-- Původní zpráva --
Od: Eric Velten de Melo ericvm...@gmail.com
Datum: 11. 9. 2012
Předmět: [Haskell-cafe] Either Monad and Laziness
Hello,
I am
One day, I _really_ should learn all GHCI commands...
Thanks, Felipe ^^
2012/1/25 Felipe Almeida Lessa felipe.le...@gmail.com
On Wed, Jan 25, 2012 at 7:38 PM, Yves Parès yves.pa...@gmail.com wrote:
But I haven't found a way to tell GHCI to fully evaluate 'x' but _not_
print
its value.
Thanks!
I released it:
http://hackage.haskell.org/package/htrace
http://github.com/jkff/htrace
On Wed, Jan 25, 2012 at 4:18 AM, Felipe Almeida Lessa
felipe.le...@gmail.com wrote:
Really nice! Looks like it could be a useful mini-package on Hackage.
--
Felipe.
--
Eugene Kirpichov
Look how one can watch the evaluation tree of a computation, to debug
laziness-related problems.
You might like the old Hood/GHood:
http://hackage.haskell.org/package/hood
http://hackage.haskell.org/package/GHood
Background info/papers:
http://www.ittc.ku.edu/csdl/fpg/Tools/Hood
http
Hi, nice little package!
I just made a fork and added a new function makeHTrace to be able to have
separate variables 'level'.
I also add the htrace type signature (or else haddock won't generate
documentation for this module):
https://github.com/YwenP/htrace
I was also investigating in a way to
On Wed, Jan 25, 2012 at 7:38 PM, Yves Parès yves.pa...@gmail.com wrote:
But I haven't found a way to tell GHCI to fully evaluate 'x' but _not_ print
its value.
Use the :force, Yves!
let {a = htrace a 12; b = htrace b 29; c = htrace c 10; d = htrace d
90; x = htrace , (htrace + (a+b), htrace
Hi cafe,
Look how one can watch the evaluation tree of a computation, to debug
laziness-related problems.
{-# LANGUAGE BangPatterns #-}
module HTrace where
import Data.List (foldl')
import Data.IORef
import System.IO.Unsafe
level = unsafePerformIO $ newIORef 0
htrace str x = unsafePerformIO
] []
:
:
:
:
:
:
:
:
:
:
ys
[10,9,8,7,6,5,4,3,2,1]
Thanks for sharing!
On 25 January 2012 01:47, Eugene Kirpichov ekirpic...@gmail.com wrote:
Hi cafe,
Look how one can watch the evaluation tree of a computation, to debug
laziness-related problems
Really nice! Looks like it could be a useful mini-package on Hackage.
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
2011/5/3 Manuel M T Chakravarty c...@cse.unsw.edu.au:
Interestingly, today (at least the academic fraction of) the Haskell
community appears to hold the purity of the language in higher
regard than its laziness.
I find Greg Morissett's comment on Lennart Augustsson's article pro
lazy
On Tue, May 3, 2011 at 1:32 AM, Manuel M T Chakravarty
c...@cse.unsw.edu.au wrote:
... Interestingly, today (at least the academic fraction of) the Haskell
community appears to hold the purity of the language in higher regard than its
laziness.
As someone who implemented Haskell with quite
On Tue, May 3, 2011 at 2:26 AM, Dominique Devriese
dominique.devri...@cs.kuleuven.be wrote:
What I find interesting is that he considers (non-)termination an
effect, which Haskell does not manage to control like it does other
types of effects. Dependently typed purely functional languages like
I completely agree that laziness enables a number of nice coding idioms and, as
Lennart described so eloquently, it does facilitate a combinator-based coding
style among other things:
http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html
(Note that even Bob admits
opinion from somebody who knows a bit about the
business.
Recently, he had a piece on monads, and how to do them in ML, and one
statement puzzled me:
There is a particular reason why monads had to arise in Haskell,
though, which is to defeat the scourge of laziness.
My own view
Yes, I'm following it too, and it seems to me that Harper just allows his
dislike for Haskell to take advantage of his judgement. Monads as a way to deal
with laziness are a very common misconception.
Отправлено с iPhone
May 2, 2011, в 11:54, Ketil Malde ke...@malde.org написал(а):
I'm
On 2011-05-02 03:54, Ketil Malde wrote:
There is a particular reason why monads had to arise in Haskell,
though, which is to defeat the scourge of laziness.
I wonder if there are any other rationale for a statement like that?
He spends one paragraph dismissing the usefulness
2011/5/2 Ketil Malde ke...@malde.org:
There is a particular reason why monads had to arise in Haskell,
though, which is to defeat the scourge of laziness.
My own view is/was that monads were so successful in Haskell since it
allowed writing flexible programs with imperative features
On Mon, May 2, 2011 at 9:29 AM, Dominique Devriese
dominique.devri...@cs.kuleuven.be wrote:
I agree with your analysis. Throughout his different articles, I think
Harper partly has a point when he says that laziness brings certain
disadvantages (like e.g. complex memory and CPU behaviour
the scourge of laziness.
My own view is/was that monads were so successful in Haskell since it
allowed writing flexible programs with imperative features, without
sacrificing referential transparency. Although people are quick (and
rightly so) to point out that this flexibility goes way beyond IO, I
Tony Morris:
Interesting how I have been authoring and subsequently using monads in
scala for several years and it is strictness that gets in the way more
than anything.
Just to make sure that I understand you correctly. You are saying that when
you use monads in Scala, then strictness makes
the language designers. Interestingly, today (at least the
academic fraction of) the Haskell community appears to hold the purity of the
language in higher regard than its laziness.
Manuel
Ketil Malde:
I'm following Harper's blog, Existential Type¹, which I find to be an
enjoyable
-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Akio Takano
| Sent: 07 February 2011 04:10
| To: glasgow-haskell-users@haskell.org
| Subject: Dictionaries and full laziness transformation
|
| Hi,
|
| I'm using GHC 7.0.1. I found
7.27s ( 7.28s elapsed)
%GC time 36.1% (36.0% elapsed)
Alloc rate4,905,159,063 bytes per MUT second
Productivity 63.8% of total user, 63.8% of total elapsed
while compiling with -O2 and -fno-full-laziness or -O0 reverts memory
usage back to constant:
./enumSequence-main +RTS -s
1
Hi,
I'm using GHC 7.0.1. I found that recursive overloaded functions tend
to leak memory when compiled with full-laziness optimization on. Here
is a simple case.
-- TestSub.hs
{-# LANGUAGE BangPatterns #-}
module TestSub where
{-# NOINLINE factorial #-}
factorial :: (Num
Max Bolingbroke schrieb:
Let's start with a simple example of an existential data type:
data Stream a = forall s. Stream s (s - Maybe (a, s))
I use quite the same data type for my signal processing applications:
http://code.haskell.org/synthesizer/core/src/Synthesizer/State/Signal.hs
You
On 19 October 2010 19:01, Dan Doel dan.d...@gmail.com wrote:
However, this argument is a bit circular, since that eliminator could be
defined to behave similarly to an irrefutable match.
Right.
Or, put another
way, eta expansion of a dictionary-holding existential would result in a value
On Friday 22 October 2010 5:48:28 am Max Bolingbroke wrote:
I think evaluating dictionaries strictly is more of a want to have
rather than actually implemented. In particular, GHC supports
building value-recursive dictionaries - and making dictionary
arguments strict indiscriminately would
On 22 October 2010 12:03, Dan Doel dan.d...@gmail.com wrote:
data Mu f = In { out :: f (Mu f) }
instance Show (f (Mu f)) = Show (Mu f) where
show = show . out
Is that an example of a value recursive dictionary?
Assuming the Show (f (Mu f)) instance uses the (Mu f) one, AFAIK this
Max Bolingbroke wrote:
Let's start with a simple example of an existential data type:
data Stream a = forall s. Stream s (s - Maybe (a, s))
ones :: Stream Int
ones = cons 1 ones
Unfortunately, 'ones' is just _|_! The reason is that cons is strict
in its second argument. The problem I
Hi Oleg,
Thanks for your reply!
Really? Here are two 'cons' that seem to satisfy all the criteria
Thanks - your definitions are similar to Roman's suggestion.
Unfortunately my criteria 3) is not quite what I actually wanted - I
really wanted something GHC-optimisable - (so non-recursive
On Tuesday 19 October 2010 6:16:16 am Max Bolingbroke wrote:
Thanks - your definitions are similar to Roman's suggestion.
Unfortunately my criteria 3) is not quite what I actually wanted - I
really wanted something GHC-optimisable - (so non-recursive
definitions are a necessary but not
On 16/10/2010, at 12:36, Max Bolingbroke wrote:
On 16 October 2010 12:16, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
eta :: Stream a - Stream a
eta s = Stream s next
where
next (Stream s next') = case next' s of
Just (x,s') - Just (x,Stream s' next')
Hi Cafe,
I've run across a problem with my use of existential data types,
whereby programs using them are forced to become too strict, and I'm
looking for possible solutions to the problem.
I'm going to explain what I mean by using a literate Haskell program.
First, the preliminaries:
{-#
On 16/10/2010, at 12:00, Max Bolingbroke wrote:
Hi Cafe,
I've run across a problem with my use of existential data types,
whereby programs using them are forced to become too strict, and I'm
looking for possible solutions to the problem.
I'm going to explain what I mean by using a
On 16 October 2010 12:16, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
eta :: Stream a - Stream a
eta s = Stream s next
where
next (Stream s next') = case next' s of
Just (x,s') - Just (x,Stream s' next')
Nothing -
On Wed, Sep 1, 2010 at 1:00 PM, Daniel Fischer daniel.is.fisc...@web.dewrote:
I'm not keen on subscribing to libraries@ to follow the official proposal
process, any takers?
I'll take it up.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Wednesday 01 September 2010 21:29:47, Daniel Fischer wrote:
that's where you definitely get a space leak, because
intersperse :: a - [a] - [a]
intersperse _ [] = []
intersperse _ [x] = [x]
intersperse sep (x:xs) = x : sep : intersperse sep xs
isn't lazy enough.
On Tue, 03 Aug 2010 16:36:33 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
- If there is no class instance for function types, then those problems
go away, of course. But it is doubtful whether that would be a viable
solution. Quite a few programs
Nicolas Pouillard schrieb:
Actually I think we can keep the old generic seq, but cutting its full
polymorphism:
seq :: Typeable a = a - b - b
I guess I don't know enough about Typeable to appreciate that.
Basically the Typeable constraints tells that we dynamically know the identity
of the
On Wed, 04 Aug 2010 15:41:54 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
Actually I think we can keep the old generic seq, but cutting its full
polymorphism:
seq :: Typeable a = a - b - b
I guess I don't know enough about Typeable to
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe function you are on
your own.
Clearer?
Almost. What I am missing is whether or not you would then consider your
genericSeq (which is applicable to functions) one of those unsafe
functions or not.
Ciao,
Janis.
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe function you are on
your own.
Clearer?
Almost. What I am missing is whether or not you would then consider your
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe function you are on
your own.
Clearer?
Almost. What I am missing is whether or not you would
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the
On Wed, 04 Aug 2010 18:04:13 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
Nicolas Pouillard schrieb:
Right let's make it more explicit, I actually just wrote a Control.Seq
module and a test file:
module Control.Seq where
genericSeq :: Typeable a = a - b - b
genericSeq = Prelude.seq
class Seq a where
seq :: a - b - b
instance (Typeable a,
On Mon, 02 Aug 2010 17:41:02 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Hi,
I am late to reply in this thread, but as I see Stefan has already made
what (also from my view) are the main points:
- Putting seq in a type class makes type signatures more verbose, which
one
Nicolas,
OK, I better understand now where we disagree. You want to see in the type
whether or not the free theorem apply, I want them to always apply when
no call to unsafe function is made.
Implementing your suggestion would make me feel uncomfortable. Turning seq into
an unsafe operations
Nicolas Pouillard schrieb:
- If there is no class instance for function types, then those problems
go away, of course. But it is doubtful whether that would be a viable
solution. Quite a few programs would be rejected as a consequence. (Say,
you want to use the strict version of foldl. That will
Hi again,
Maybe I should add that, maybe disappointingly, I do not even have a
strong opinion about whether seq should be in Haskell or not, and in
what form. Let me quote the last paragraph of an extended version of our
paper referred to earlier:
Finally, a natural question is whether or not
On Tue, 3 Aug 2010 16:24:54 +0200, Stefan Holdermans ste...@vectorfabrics.com
wrote:
Nicolas,
OK, I better understand now where we disagree. You want to see in the type
whether or not the free theorem apply, I want them to always apply when
no call to unsafe function is made.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/3/10 10:24 , Stefan Holdermans wrote:
Implementing your suggestion would make me feel uncomfortable. Turning seq
into an unsafe operations effectively places it outside the language, like
unsafePerformIO isn't really part of the language (in
Nicolas, Luke,
SH More importantly, the type-class approach is flawed [...]. It assumes
SH that all seq-related constraints can be read off from type variables,
SH which is in fact not the case.
LP Could you provide an example (or a specific example or explanation in
LP the paper) of what you
Hi,
I am late to reply in this thread, but as I see Stefan has already made
what (also from my view) are the main points:
- Putting seq in a type class makes type signatures more verbose, which
one may consider okay or not. In the past (and, as it seems, again in
every iteration of the language
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/10 11:41 , Janis Voigtländer wrote:
alright that we don't know more about where (==) is used. But for a
function of type f :: Eval (a - Int) = (a - Int) - (a - Int) -
Int, in connection with trying to find out whether uses of seq are
Brandon,
Hm. Seems to me that (with TypeFamilies and FlexibleContexts)
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
should do that, but ghci is telling me it isn't (substituting Eq for Eval
for the nonce):
Prelude let h :: (x ~ y, Eq (y - Int)) = (x - Int) - (y - Int) -
Brandon,
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
But actually if you push the constraint inward, into the type so to say, you
actually get quite close to Janis' and David's solution.
Sorry, I was thinking out loud there. I meant the Eval constraint, not the
equality
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/10 17:18 , Stefan Holdermans wrote:
Brandon,
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
But actually if you push the constraint inward, into the type so to say,
you actually get quite close to Janis' and David's
Brandon,
Sorry, I was thinking out loud there. I meant the Eval constraint, not the
equality constraint. But, right now, I guess my comment only makes sense to
me, so let's pretend I kept quiet. ;-)
The point of this discussion is that the Eval constraint needs to be on one
of the
Brandon S Allbery KF8NH allb...@ece.cmu.edu writes:
Exactly. (I was being cagey because the first response was cagey, possibly
suspecting a homework question although it seems like an odd time for
it.)
Why is it an odd time for it?
Here in Australia (and presumably other countries in the
On Sat, 31 Jul 2010 17:30:54 -0400, Brandon S Allbery KF8NH
allb...@ece.cmu.edu wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 16:58 , wren ng thornton wrote:
Brandon S Allbery KF8NH wrote:
michael rice wrote:
Are you saying:
[ head x ] - [ *thunk* ] and
Nicolas,
I would deeply in favor of renaming seq to unsafeSeq, and introduce a
type class to reintroduce seq in a disciplined way.
There is a well-documented [1] trade-off here: Often, calls to seq are
introduced late in a developing cycle; typically after you have discovered a
space leak
On Sun, Aug 1, 2010 at 2:53 AM, Stefan Holdermans
ste...@vectorfabrics.com wrote:
Nicolas,
I would deeply in favor of renaming seq to unsafeSeq, and introduce a
type class to reintroduce seq in a disciplined way.
There is a well-documented [1] trade-off here: Often, calls to seq are
On Sun, 1 Aug 2010 10:53:24 +0200, Stefan Holdermans ste...@vectorfabrics.com
wrote:
Nicolas,
I would deeply in favor of renaming seq to unsafeSeq, and introduce a
type class to reintroduce seq in a disciplined way.
There is a well-documented [1] trade-off here: Often, calls to seq are
On Sun, Aug 1, 2010 at 11:29 AM, Nicolas Pouillard
nicolas.pouill...@gmail.com wrote:
Finally maybe we can simply forbidden the forcing of function (as we do with
Eq). The few cases where it does matter will rescue to unsafeSeqFunction.
What's the problem with
class Eval a where
seq :: a
On Sunday 01 August 2010 10:52:48 am Felipe Lessa wrote:
On Sun, Aug 1, 2010 at 11:29 AM, Nicolas Pouillard
nicolas.pouill...@gmail.com wrote:
Finally maybe we can simply forbidden the forcing of function (as we do
with Eq). The few cases where it does matter will rescue to
From: http://en.wikibooks.org/wiki/Haskell/Laziness
Given two functions of one parameter, f and g, we say f is stricter than g if f
x evaluates x to a deeper level than g x
Exercises
1. Which is the stricter function?
f x = length [head x]
g x = length (tail x)
Prelude let f x = length
michael rice schrieb:
So, g is stricter than f?
Wouldn't both functions need to evaluate x to the same level, *thunk* :
*thunk* to insure listhood?
No. :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Sat, Jul 31, 2010 at 4:56 PM, michael rice nowg...@yahoo.com wrote:
From: http://en.wikibooks.org/wiki/Haskell/Laziness
Given two functions of one parameter, f and g, we say f is stricter than g if
f x evaluates x to a deeper level than g x
Exercises
1. Which is the stricter
@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Notice the two different kinds of brackets being used in f versus g :)
--- On Sat, 7/31/10, Ben Millwood hask...@benmachine.co.uk wrote:
From: Ben Millwood hask...@benmachine.co.uk
Subject: Re: [Haskell-cafe] Laziness question
To: michael
the [] and ().
But since both still have eval x to *thunk* : *thunk*, g evaluates to a
deeper level?
The whole point of laziness is that f *doesn't* have to eval x.
- --
brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb
On Sat, Jul 31, 2010 at 5:59 PM, michael rice nowg...@yahoo.com wrote:
OK, in f, *length* already knows it's argument is a list.
In g, *length* doesn't know what's inside the parens, extra evaluation there.
So g is already ahead before we get to what's inside the [] and ().
According to the
On 10-07-31 01:30 PM, Brandon S Allbery KF8NH wrote:
On 7/31/10 12:59 , michael rice wrote:
But since both still have eval x to *thunk* : *thunk*, g evaluates to a
deeper level?
The whole point of laziness is that f *doesn't* have to eval x.
To elaborate, in computer-friendly syntax:
f x
] - [ *thunk* ] and length [ *thunk* ] - 1, independent of
what *thunk* is, even head [], i.e., *thunk* never needs be evaluated?
Michael
--- On Sat, 7/31/10, Ben Millwood hask...@benmachine.co.uk wrote:
From: Ben Millwood hask...@benmachine.co.uk
Subject: Re: [Haskell-cafe] Laziness
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 14:24 , michael rice wrote:
Are you saying:
[ head x ] - [ *thunk* ] and length [ *thunk* ] - 1, independent of
what *thunk* is, even head [], i.e., *thunk* never needs be evaluated?
Exactly. (I was being cagey because the
michael rice wrote:
f x = length [head x]
g x = length (tail x)
Wouldn't both functions need to evaluate x to the same level, *thunk* :
*thunk* to insure listhood?
There is no need to insure listhood at run time, since Haskell is
statically typed.
Tillmann
Subtle stuff.
Thanks, everyone, for your patience. You've been VERY helpful. Great list!
Michael
--- On Sat, 7/31/10, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote:
From: Brandon S Allbery KF8NH allb...@ece.cmu.edu
Subject: Re: [Haskell-cafe] Laziness question
To: haskell-cafe@haskell.org
Brandon S Allbery KF8NH wrote:
michael rice wrote:
Are you saying:
[ head x ] - [ *thunk* ] and length [ *thunk* ] - 1, independent of
what *thunk* is, even head [], i.e., *thunk* never needs be evaluated?
Exactly. (I was being cagey because the first response was cagey, possibly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 16:58 , wren ng thornton wrote:
Brandon S Allbery KF8NH wrote:
michael rice wrote:
Are you saying:
[ head x ] - [ *thunk* ] and length [ *thunk* ] - 1, independent of
what *thunk* is, even head [], i.e., *thunk* never needs be
#3944: Asynchronous exceptions and laziness bugs (with fixes) in
Control.Concurrent.QSem/QSemN
-+--
Reporter: basvandijk | Owner: simonmar
Type: bug | Status: closed
Hi Daniel,
Thank you very much for the explanation of this issue.
While I understand the parts about rewrite rules and the big thunk, it
is still not clear why it is the way it is.
Please could you explain which Nums are not strict? The ones I am aware
about are all strict.
Also, why doesn't
min _ Zero = Zero
min (Succ m) (Succ n) = Succ (min m n)
max Zero n = n
max m Zero = m
max (Succ m) (Succ n) = Succ (max m n)
instance Num Peano where
Zero + n = n
(Succ m) + n = Succ (m + n)
-- omitted other methods due to laziness (mine, not Haskell's)
fromInteger n
On 14.06.10 17:25, Serge D. Mechveliani wrote:
lng [1 .. n] =
lng (1 : (list 2 n)) = 1 + (lng $ list 2 n) =
1 + (lng (2: (list 3 n))) = 1 + 1 + (lng $ list 3 n) = {- !!! -}
2 + (lng (3: (list 4 n))) -- because this + is of Integer
= 2 + 1 + (lng $ list 4 n) = {- !!! -}
3 + (lng $
Dear people and GHC team,
I have a naive question about the compiler and library of ghc-6.12.3.
Consider the program
import List (genericLength)
main = putStr $ shows (genericLength [1 .. n]) \n
where
n = -- 10^6, 10^7, 10^8 ...
(1) When it is compiled under -O,
On Monday 14 June 2010 16:25:06, Serge D. Mechveliani wrote:
Dear people and GHC team,
I have a naive question about the compiler and library of ghc-6.12.3.
Consider the program
import List (genericLength)
main = putStr $ shows (genericLength [1 .. n]) \n
where
n =
#3944: Asynchronous exceptions and laziness bugs (with fixes) in
Control.Concurrent.QSem/QSemN
-+--
Reporter: basvandijk|Owner: simonmar
Type: bug | Status: patch
1 - 100 of 375 matches
Mail list logo
