Ariel J. Birnbaum wrote:
(considering undefined as equivalent to const undefined, which iirc was
the definition of _|_ for function types).
What am I missing?
undefined /= const undefined
in Haskell, due to seq.
--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
GHC already ignores the existence of seq, for instance when doing list
fusion.
The unconstrained seq function just ruins too many things.
I say, move seq top a type class (where is used to be), and add an unsafeSeq
for people who want to play dangerously.
-- Lennart
On Tue, May 6, 2008 at 3:27
Thanks both for the the explanation and the link. The wikibook is really
growing fast!
Abhay
On Wed, May 7, 2008 at 5:05 PM, apfelmus [EMAIL PROTECTED] wrote:
Abhay Parvate wrote:
Just for curiocity, is there a practically useful computation that uses
'seq' in an essential manner, i.e.
Luke Palmer wrote:
It seems that there is a culture developing where people intentionally
ignore the existence of seq when reasoning about Haskell. Indeed I've
heard many people argue that it shouldn't be in the language as it is
now, that instead it should be a typeclass.
I wonder if it's
Just for curiocity, is there a practically useful computation that uses
'seq' in an essential manner, i.e. apart from the efficiency reasons?
Abhay
On Wed, May 7, 2008 at 2:48 PM, apfelmus [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
It seems that there is a culture developing where people
Abhay Parvate wrote:
Just for curiocity, is there a practically useful computation that uses
'seq' in an essential manner, i.e. apart from the efficiency reasons?
I don't think so because you can always replace seq with const id .
In fact, doing so will get you more results, i.e. a
On 5/4/08, Iavor Diatchki [EMAIL PROTECTED] wrote:
From the monad law we can conclude only that (= return) is strict,
not (=) in general.
For example, (=) for the reader monad is not strict in its first argument:
m = f = \r - f (m r) r
So, (undefined return 2) = (return 2)
That's not even
Hello,
On Sat, May 3, 2008 at 3:56 AM, apfelmus [EMAIL PROTECTED] wrote:
Bryan Donlan wrote:
evaluate x = (return $! x) = return
However, if = is strict on its first argument, then this definition is
no better than (return $! x).
According to the monad law
f =
Bryan Donlan wrote:
evaluate x = (return $! x) = return
However, if = is strict on its first argument, then this definition is
no better than (return $! x).
According to the monad law
f = return = f
every (=) ought to be strict in its first argument, so it indeed seems
that
apfelmus wrote:
Bryan Donlan wrote:
evaluate x = (return $! x) = return
However, if = is strict on its first argument, then this definition is
no better than (return $! x).
According to the monad law
f = return = f
every (=) ought to be strict in its first argument, so it indeed
10 matches
Mail list logo
