On Sun, Jan 22, 2012 at 5:25 PM, David Barbour dmbarb...@gmail.com wrote:
The laws for monads only apply to actual values and combinators of the monad
algebra
You seem to argue that, even in a lazy language like Haskell,
equational laws should be considered only for values, as if they where
Thanks for the reference. I base my opinion on my own observations - e.g.
the repeated failures of attempting to model stream processing with
infinite lists, the relative success of modeling exceptions explicitly with
monads compared to use of `fail` or SomeException, etc..
On Mon, Jan 23, 2012
On Mon, Jan 23, 2012 at 10:45 AM, David Barbour dmbarb...@gmail.com wrote:
the repeated failures of attempting to model stream processing with infinite
lists,
I'm curious about what failures you're talking about.
- Jake
___
Haskell-Cafe mailing list
Space leaks, time leaks, resource leaks, subtle divergence issues when
filtering lists, etc.
On Mon, Jan 23, 2012 at 11:57 AM, Jake McArthur jake.mcart...@gmail.comwrote:
On Mon, Jan 23, 2012 at 10:45 AM, David Barbour dmbarb...@gmail.com
wrote:
the repeated failures of attempting to model
On Sat, Jan 21, 2012 at 8:09 PM, David Barbour dmbarb...@gmail.com wrote:
In any case, I think the monad identity concept messed up. The property:
return x = f = f x
Logically only has meaning when `=` applies to values in the domain.
`undefined` is not a value in the domain.
We can
observably different from `undefined`
If we understand `undefined` as meaning a computation that never ends, then
you cannot ever observe whether one `undefined` is or is not equivalent to
another. In strict languages, this is especially obvious.
In any case, I don't accept a concept of
Отправлено с iPad
22.01.2012, в 20:25, David Barbour dmbarb...@gmail.com написал(а):
Attempting to shoehorn `undefined` into your reasoning about domain algebras
and models and monads is simply a mistake.
No. Using the complete semantics — which includes bottoms aka undefined — is a
2012/1/22 MigMit miguelim...@yandex.ru
Отправлено с iPad
22.01.2012, в 20:25, David Barbour dmbarb...@gmail.com написал(а):
Attempting to shoehorn `undefined` into your reasoning about domain
algebras and models and monads is simply a mistake.
No. Using the complete semantics — which
The do notation translates
do {x - a;f} into
a=(\x - f)
However when we're working in the IO monad the semantics we want requires that
the lambda expression be strict in its argument. So is this a special case for
IO? If I wanted this behavior in other monads is there a way to specify
On 21 Jan 2012, at 21:29, Victor S. Miller wrote:
The do notation translates
do {x - a;f} into
a=(\x - f)
However when we're working in the IO monad the semantics we want requires
that the lambda expression be strict in its argument. So is this a special
case for IO? If I wanted
* Victor S. Miller victorsmil...@gmail.com [2012-01-21 12:29:32-0500]
The do notation translates
do {x - a;f} into
a=(\x - f)
However when we're working in the IO monad the semantics we want
requires that the lambda expression be strict in its argument.
I'm not aware of any semantics
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would be trivial to model a transformer monad to provide it.
E.g.
data StrictT m a = StrictT (m a)
runStrictT :: StrictT m a - m a
runStrictT (StrictT
On 21/01/2012 17:29, Victor S. Miller wrote:
The do notation translates
do {x- a;f} into
a=(\x - f)
However when we're working in the IO monad the semantics we want requires that
the lambda expression be strict in its argument. So is this a special case for
IO? If I wanted this behavior
* David Barbour dmbarb...@gmail.com [2012-01-21 10:01:00-0800]
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would be trivial to model a transformer monad to provide it.
Again, that wouldn't be a
On 21/01/2012 18:08, Steve Horne wrote:
Even so, to see that strictness isn't the issue, imagine that (=)
were rewritten using a unary executeActionAndExtractResult function.
You could easily rewrite your lamba to contain this expression in
place of x, without actually evaluating that
On Sat, Jan 21, 2012 at 10:08 AM, Roman Cheplyaka r...@ro-che.info wrote:
* David Barbour dmbarb...@gmail.com [2012-01-21 10:01:00-0800]
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would be
On Sat, Jan 21, 2012 at 1:45 PM, David Barbour dmbarb...@gmail.com wrote:
On Sat, Jan 21, 2012 at 10:08 AM, Roman Cheplyaka r...@ro-che.info wrote:
* David Barbour dmbarb...@gmail.com [2012-01-21 10:01:00-0800]
As noted, IO is not strict in the value x, only in the operation that
generates
On Sat, Jan 21, 2012 at 10:51 AM, David Menendez d...@zednenem.com wrote:
The Eval monad has the property: return undefined = const e = e.
You can't write `const e` in the Eval monad.
From what I can tell, your proposed monads do not.
You can't write `const e` as my proposed monad,
* David Barbour dmbarb...@gmail.com [2012-01-21 11:02:40-0800]
On Sat, Jan 21, 2012 at 10:51 AM, David Menendez d...@zednenem.com wrote:
The Eval monad has the property: return undefined = const e = e.
You can't write `const e` in the Eval monad.
Why not?
ghci runEval $ return
Oops, I was misreading. You have `e` here as the next monad.
In any case, I think the monad identity concept messed up. The property:
return x = f = f x
Logically only has meaning when `=` applies to values in the domain.
`undefined` is not a value in the domain.
We can define monads - which
On Sat, Jan 21, 2012 at 11:08 AM, Roman Cheplyaka r...@ro-che.info wrote:
* David Barbour dmbarb...@gmail.com [2012-01-21 11:02:40-0800]
On Sat, Jan 21, 2012 at 10:51 AM, David Menendez d...@zednenem.com
wrote:
The Eval monad has the property: return undefined = const e = e.
You
* David Barbour dmbarb...@gmail.com [2012-01-21 11:09:43-0800]
Logically only has meaning when `=` applies to values in the domain.
`undefined` is not a value in the domain.
We can define monads - which meet monad laws - even in strict languages.
In strict languages 'undefined' is not a
(StrictT op) = f = StrictT (op = \ x - x `seq` runStrictT (f x))
Are you sure? Here you evaluate the result, and not the computation itself.
Wouldn't it be:
(StrictT op) = f = op ` seq` StrictT (op = \x - runStrictT (f x))
??
2012/1/21 David Barbour dmbarb...@gmail.com
On Sat, Jan 21, 2012
Evaluating the argument/result was my intention. Evaluating the computation
itself might be useful in some cases, though.
Regards,
Dave
On Sat, Jan 21, 2012 at 3:20 PM, Yves Parès yves.pa...@gmail.com wrote:
(StrictT op) = f = StrictT (op = \ x - x `seq` runStrictT (f x))
Are you sure?
24 matches
Mail list logo
