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
21 matches
Mail list logo
