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 counte
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 th
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
unsa
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
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
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 limitatio
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: Wh
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
> unsafePerformI
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 20
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.
> 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
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.
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?
--
> "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
"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 f
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 mi
George Russel wrote:
[snip]
> I presume it would not in fact be difficult to synthesise a left identity at
> the cost of making things slower, thus (forgive any syntax errors, I'm not going to
> test this).
>
> data MonadIO a = Action (IO a) | Return a
> instance Monad (MonadIO a) where
>retu
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 quo
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 even
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 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 applie
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 foll
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 following should hold
in the IO monad:
(return
23 matches
Mail list logo