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.
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/31/10 12:59 , michael rice 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 ().
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
On Thu, Jul 16, 2009 at 9:57 PM, Ryan Ingramryani.s...@gmail.com wrote:
On Thu, Jul 16, 2009 at 8:22 PM, Thomas Hartmantphya...@gmail.com wrote:
Is this being worked on?
On Thu, Jul 16, 2009 at 12:35 PM, Bas van Dijkv.dijk@gmail.com wrote:
I have no idea.
Yes.
Bolingbroke,
Thomas, if you did no know, where to look for `lazy-memory-hole', say
in your first example, how would you go about solving that puzzle
systematically with a Profiler (or other tools)?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
I don't have a good answer to that, and I unable to reliably solve
this type of problem, which is one reason I am posting around on
haskell cafe hoping to accumulate wisdom.
Here for instance I think I did
t = last . take (10^6) $ repeat $ S.empty
which doesn't blow up, and by process of
I tried using your original code and stuffing it into a profiler. But
all I get is a triangle of linearly increasing resource usage, and
then it breaks for lack of stack. I guess I am just to ignorant about
retainer profiling and such stuff.
___
On Wed, Jul 15, 2009 at 6:35 PM, Ryan Ingramryani.s...@gmail.com wrote:
iterate' f x = x `seq` x : iterate' f (f x)
seems better; it doesn't evaluate list elements you don't visit.
iterate'' f x = x : (iterate'' f $! f x)
...seems the most lazy strict iterate.
(Bas wishes for a type system
the strict functions seem very nice, will they eventually make their way into
http://hackage.haskell.org/packages/archive/Stream/0.3.2/doc/html/Data-Stream.html
?
where is Control.Monad.StreamT? couldn't find it.
2009/7/15 Bas van Dijk v.dijk@gmail.com:
On Wed, Jul 15, 2009 at 3:02 AM,
I played with this a bit, and ok, it seems the difference between
iterate' and iterate'' is
h _ = 2
tit' = head . drop 1 . iterate' h $ undefined
tit'' = head . drop 1 . iterate'' h $ undefined
(Bas wishes for a type system that can express the different
strictness properties of these
On Thu, Jul 16, 2009 at 7:45 PM, Thomas Hartmantphya...@gmail.com wrote:
the strict functions seem very nice, will they eventually make their way into
http://hackage.haskell.org/packages/archive/Stream/0.3.2/doc/html/Data-Stream.html
Note that there are two stream packages:
* 'Stream' by
On Thu, Jul 16, 2009 at 8:22 PM, Thomas Hartmantphya...@gmail.com wrote:
I played with this a bit, and ok, it seems the difference between
iterate' and iterate'' is
h _ = 2
tit' = head . drop 1 . iterate' h $ undefined
tit'' = head . drop 1 . iterate'' h $ undefined
Exactly, iterate' first
On Thu, Jul 16, 2009 at 8:22 PM, Thomas Hartmantphya...@gmail.com wrote:
Is this being worked on?
On Thu, Jul 16, 2009 at 12:35 PM, Bas van Dijkv.dijk@gmail.com wrote:
I have no idea.
Yes.
Bolingbroke, Peyton-Jones. Types are calling conventions
http://lambda-the-ultimate.org/node/3319
On Wed, Jul 15, 2009 at 3:02 AM, Thomas Hartmantphya...@gmail.com wrote:
Please suggest more of these types of exercises if you have them and
maybe we can collect the folk wisdom into a wiki page and/or exercise
page for beginners.
My 'stream' library[1] also has some examples. Look at the
On Tue, Jul 14, 2009 at 6:02 PM, Thomas Hartmantphya...@gmail.com wrote:
myiterate f x =
let nxt = f x
in nxt `seq` x : myiterate f nxt
iterate' f x = x `seq` x : iterate' f (f x)
seems better; it doesn't evaluate list elements you don't visit.
let test = 1 : 2 : 3 : undefined in last $
Challenge: change one function in the following pipeline so that t
doesn't blow up when executed in ghci.
import qualified Data.Set as S
t = last . take (10^6) . iterate f $ S.empty
f s = S.delete 1 . S.insert 1 $ s
Please suggest more of these types of exercises if you have them and
maybe we
2009/7/9 Marcin Kosiba marcin.kos...@gmail.com:
On Thursday 09 July 2009, Cristiano Paris wrote:
Thanks. In fact, I was stuck trying to find an example which couldn't
be written using Python's iterators. The only difference coming up to
my mind was that Haskell's lists are a more natural way
Thomas Davie wrote:
On 9 Jul 2009, at 14:55, Cristiano Paris wrote:
I'm wondering what a good example of why laziness enhances
composability would be.
I'm specifically looking for something that can't implemented in
Python with iterators (at least not elegantly), but can actually be
Hi,
I'm wondering what a good example of why laziness enhances composability
would be.
I'm specifically looking for something that can't implemented in Python with
iterators (at least not elegantly), but can actually be implemented in
Haskell.
Thanks,
Cristiano
Hello,
A wonderful, and practical example, is the techniques in this modular lazy
search paper:
http://web.cecs.pdx.edu/~apt/jfp01.ps
They build simple solvers, like backtracking, backjumping, etc. and
then compose them together like: bt . bj
The techniques are very much based on laziness.
On 9 Jul 2009, at 14:55, Cristiano Paris wrote:
Hi,
I'm wondering what a good example of why laziness enhances
composability would be.
I'm specifically looking for something that can't implemented in
Python with iterators (at least not elegantly), but can actually be
implemented in
Thank you for your suggestions!
C.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello Cristiano,
Thursday, July 9, 2009, 4:55:09 PM, you wrote:
the best known example is chessmate implementation in Wadler's why
functional programming matter
but i don't know much about Python iterators, so can't say what is
difference. may be its' only simplicity since lazy lists is looks
On Thu, Jul 9, 2009 at 3:42 PM, Bulat Ziganshin
bulat.zigans...@gmail.com wrote:
Hello Cristiano,
Thursday, July 9, 2009, 4:55:09 PM, you wrote:
the best known example is chessmate implementation in Wadler's why
functional programming matter
but i don't know much about Python iterators,
Bulat Ziganshin wrote:
Hello Cristiano,
Thursday, July 9, 2009, 4:55:09 PM, you wrote:
the best known example is chessmate implementation in Wadler's why
functional programming matter
Aeh, ... Wadler's - Hughes'
--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
On Thursday 09 July 2009, Cristiano Paris wrote:
Thanks. In fact, I was stuck trying to find an example which couldn't
be written using Python's iterators. The only difference coming up to
my mind was that Haskell's lists are a more natural way to express a
program relying on laziness. That
On Thursday 09 July 2009, you wrote:
2009/7/9 Marcin Kosiba marcin.kos...@gmail.com:
I thought I'll go the smart way and rely on the Python yield construct
to do a CPS transformation of my code.
While this worked to a certain extent, composability was a
problem, because any
On 04/06/2008, at 10:12 AM, Ronald Guida wrote:
I would ask, how do I examine the evaluation order of my code, but
the answer is already available: use a debugger. Haskell already has
debugging tools that do exactly what I need.
(http://www.haskell.org/haskellwiki/Debugging)
In particular,
Ronald Guida wrote:
[snip]
By default, a lazy language will procrastinate. By default, a strict
language will anticrastinate. Either way, I can waste resources by
blindly accepting the default time management plan.
Nice analysis.
Would you like to put that (the whole thing, not just that
I was looking at the real time queues in [1] and I wanted to see what
would happen if I tried to write one in Haskell. The easy part was
translating the real time queue from [1], p43 into Haskell.
The hard part is testing to see if the rotations really happen what
they should. Basically, I
Ronald Guida wrote:
I was looking at the real time queues in [1] and I wanted to see what
would happen if I tried to write one in Haskell. The easy part was
translating the real time queue from [1], p43 into Haskell.
The hard part is testing to see if the rotations really happen what
they
Don Stewart wrote:
2. Is there any way to systematically search for or detect laziness
leaks?
Profiling, and looking at the Core. Being explicit about the
evaluation strategy you want is a fine idea though.
Albert Y. C. Lai wrote
A true cause of laziness is in accumulating a chain of
On Tue, 2008-06-03 at 20:12 -0400, Ronald Guida wrote:
Don Stewart wrote:
2. Is there any way to systematically search for or detect laziness
leaks?
Profiling, and looking at the Core. Being explicit about the
evaluation strategy you want is a fine idea though.
Albert Y. C. Lai
On Mon, Apr 21, 2008 at 2:18 PM, John Goerzen [EMAIL PROTECTED] wrote:
Back when I was working on the logic for the bin-packing solver that I added
to MissingH (for use with datapacker), I had a design decision to make: do I
raise runtime errors with the input using error, or do I use an
On Mon, 2008-04-21 at 21:26 +0100, Magnus Therning wrote:
John Goerzen wrote:
Back when I was working on the logic for the bin-packing solver that I
added
to MissingH (for use with datapacker), I had a design decision to make: do
I
raise runtime errors with the input using error, or
Back when I was working on the logic for the bin-packing solver that I added
to MissingH (for use with datapacker), I had a design decision to make: do I
raise runtime errors with the input using error, or do I use an Either type
to return errors?
Initially, for simplicity, I just used error.
On Apr 21, 2008, at 11:18 AM, John Goerzen wrote:
In the case of using error, we can happily process the data assuming
everything will be fine, and raise an error if and when it is
encountered.
By using Either, however, any pattern match on the Left/Right
result is
going to force the
On Mon, 21 Apr 2008, Donn Cave wrote:
On Apr 21, 2008, at 11:18 AM, John Goerzen wrote:
In the case of using error, we can happily process the data assuming
everything will be fine, and raise an error if and when it is encountered.
By using Either, however, any pattern match on the
John Goerzen wrote:
Back when I was working on the logic for the bin-packing solver that I added
to MissingH (for use with datapacker), I had a design decision to make: do I
raise runtime errors with the input using error, or do I use an Either type
to return errors?
Initially, for
But when I did a simple
refactoring to use Either, it occurred to me that this switch likely
had a
negative impact on laziness.
Yes, probably.
Is this analysis sensible? If so, are there better solutions?
I notice that your Maybe-based code is written in a monadic style. If
you also
On Mon April 21 2008 3:26:04 pm Magnus Therning wrote:
In order to allow lazy decoding I ended up exporting decode' as well:
decode' :: String - [Maybe Word8]
I take it that in a situation like this, you'd have either:
[] -- success with empty result
a list full of Just x
-- success
I had a problem with strictness in the Parsec library, and I'd like to know
if there's a good way to solve it. The following illustrates the problem.
This raises an error when run:
main = parseTest (return undefined return 0)
Whereas this does not:
main = parseTest (return (Just
C Rodrigues wrote:
I had a problem with strictness in the Parsec library, and I'd like to
know if there's a good way to solve it. The following illustrates the
problem. This raises an error when run:
main = parseTest (return undefined return 0)
Whereas this does not:
main =
Hi --
I'm using ghc 6.6, and I had some questions about the extend of
laziness and foldr.
I've noticed the following:
x = foldr (:) [] [1..]
(take 10) x
yields [1..10]
Which is great.. however, what I'd like to fold the list over a tuple:
foo x (l,payload) = ((x:l), payload)
(x,_) = foldr
63 matches
Mail list logo
