John Launchbury wrote:
I watched with interest the discussion about the ravages of `seq`.
In the old days, we protected uses of `seq` with a type class, to keep it at
bay. There was no function instance (so no problem with the state monads, or
lifting of functions in general), and the
Yes. Let me be clear.
It is not the fact that `seq` operates on functions that breaks foldr/build:
it is the fact that `seq` claims to be parametrically polymorphic when in
fact it is not. The parametricity result is weakened to the point that the
foldr/build proof no longer applies, and a
On Tue, May 14, 2002 at 12:32:30PM -0400, Jan-Willem Maessen wrote:
Chalk me up as someone in favor of laws without exceptions.
Do you ever use floating point addition?
I rarely use floating point, but it is sometimes more useful than the
alternatives, as long as you bear in mind its
Dylan Thurston writes:
Do you ever use floating point addition?
I rarely use floating point, but it is sometimes more useful than the
alternatives, as long as you bear in mind its limitations.
Yep, floating point is by necessity a bit of a mess. On the other
hand, I don't think we ought to
I watched with interest the discussion about the ravages of `seq`.
In the old days, we protected uses of `seq` with a type class, to keep it at
bay. There was no function instance (so no problem with the state monads, or
lifting of functions in general), and the type class prevented interference
At 2002-05-15 09:48, John Launchbury wrote:
Will the next version of Haskell have something better. I hope so, but I
fear not.
Rename it unsafeSeq? No puns please...
But I think breaking Monad laws etc. is a different kind of unsafeness
from usPIO etc.
--
Ashley Yakeley, Seattle WA
On Tue, May 14, 2002, Simon Marlow wrote:
An interesting revelation just occurred to Simon P.J. and myself while
wondering about issues to do with exceptions in the IO monad (see
discussion on [EMAIL PROTECTED] if you're interested).
The question we were considering was whether the
On Tue, May 14, 2002 at 12:14:02PM +0100, Simon Marlow wrote:
The question we were considering was whether the following should hold
in the IO monad:
(return () = \_ - undefined) `seq` 42 == undefined
[as implied by the left-identity monad law]
This discrepancy applies to any
Simon Marlow wrote
[snip]
So the IO monad in Haskell, at least as we understand it, doesn't
satisfy the monad laws (or, depending on your point of view, seq breaks
the monad laws).
[snip]
Cheers Simon. One of the awkward things about the Haskell events I implemented
is that although I make
On Tue, May 14, 2002 at 04:57:12PM +0200, George Russell wrote:
According to the report
Instances of Monad should satisfy the following laws:
return a = k = k
m = return= m
m = (\x - k x = h) = (m = k) = h
so neither IO nor my events satisfy this. Up to
Dylan Thurston wrote:
[snip]
I've often been bothered by the inconsistent treatment of laws in the
report; why are there laws for functors, monads, and quot/rem and
div/mod, and not much else? I'm pleased to see that the laws that are
given actually do have exceptions.
[snip]
Even the
Dylan Thurston [EMAIL PROTECTED] writes:
I don't think this is necessarily wise to drop this from the report
altogether. To me, it seems comparable to associativity of addition
for instances of Num; many instances don't satisfy it (e.g., Float),
but it's a useful guideline to keep in mind.
S.M.Kahrs wrote:
[snip]
I don't think this really solves the problem with the left unit
(not in general, and not for IO either),
it merely pushes it to a different place.
[snip]
Not being a category theorist I find this all a bit confusing. Can you
give an example where with GHC and the fix I
S.M.Kahrs wrote:
[snip]
I don't think this really solves the problem with the left unit
(not in general, and not for IO either),
it merely pushes it to a different place.
[snip]
Not being a category theorist I find this all a bit confusing.
Nothing to do with category theory.
I took
On 2002-05-14T12:32:30-0400, Jan-Willem Maessen wrote:
And I'd really much rather we cleaned up the semantics of
seq---or better yet, fixed the problems with lazy evaluation which
make seq necessary in the first place.
A general question: What is seq useful for, other than efficiency?
--
It's useful for:
debug :: Show a = a - a
debug x = unsafePerformIO (hPutStrLn stderr (show x)) `seq` x
(Presumably trace is defined similarly)
One may ask the question: what is seq useful for not in conjunction with
unsafePerformIO, other than efficiency. That, I don't know the answer to.
-
One may ask the question: what is seq useful for not in conjunction with
unsafePerformIO, other than efficiency. That, I don't know the answer to.
Here is an example.
main::IO()
main=do
time1 - getCPUTime
w - return $! calcSomething
time2 - getCPUTime
...
J.A.
hello,
this is misleading. seq only evaluates to whnf, i.e.
the outermost lazy constructor (or lambda) and that only if the
seq ... expression is actually evaluated, which is often tricky to
ensure. furthermore, for non-functions one can get the same behaviour,
by using a case with a pattern.
True, but using seq you can define deepSeq/rnf (depening on which camp
you're from), which isn't misleading in this way.
--
Hal Daume III
Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
On Tue, 14 May
Hal Daume [EMAIL PROTECTED] writes:
[seq is] useful for:
debug :: Show a = a - a
debug x = unsafePerformIO (hPutStrLn stderr (show x)) `seq` x
(Presumably trace is defined similarly)
One may ask the question: what is seq useful for not in conjunction with
unsafePerformIO, other than
On Tue, 14 May 2002, Ken Shan wrote:
On 2002-05-14T12:32:30-0400, Jan-Willem Maessen wrote:
And I'd really much rather we cleaned up the semantics of
seq---or better yet, fixed the problems with lazy evaluation which
make seq necessary in the first place.
A general question: What is
21 matches
Mail list logo
