On Thu, May 13, 2010 at 8:13 PM, wren ng thornton w...@freegeek.org wrote:
Andrea Vezzosi wrote:
On Thu, May 13, 2010 at 10:51 AM, wren ng thornton w...@freegeek.org
wrote:
Andrea Vezzosi wrote:
wren ng thornton wrote:
With this change [1] I can't notice any difference for your
On Fri, 14 May 2010, Derek Elkins wrote:
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT r (Either e). The bind implementation for ContT is completely
independent of the underlying monad. It doesn't
Where is my bind statement doing a case analysis? Isn't it just propagating, in
a sense, the case analysis that came from values coming into the monad via
return or via throwError?
Also, why wouldn't callCC work here? I'm not that familiar with the ContT
monad so any more details would be
On Sat, May 15, 2010 at 2:28 PM, Max Cantor mxcan...@gmail.com wrote:
Where is my bind statement doing a case analysis? Isn't it just propagating,
in a sense, the case analysis that came from values coming into the monad via
return or via throwError?
What you did was reimplement the Either
On Fri, May 14, 2010 at 4:25 PM, Derek Elkins derek.a.elk...@gmail.com wrote:
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT r (Either e). The bind implementation for ContT is completely
independent
On Sat, May 15, 2010 at 9:20 PM, Antoine Latter aslat...@gmail.com wrote:
On Fri, May 14, 2010 at 4:25 PM, Derek Elkins derek.a.elk...@gmail.com
wrote:
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT
On Mon, 10 May 2010, Max Cantor wrote:
Based on some discussions in #haskell, it seemed to be a consensus that
using a modified continuation monad for Error handling instead of
Eithers would be a significant optimization since it would eliminate a
lot of conditional branching (everytime = is
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT r (Either e). The bind implementation for ContT is completely
independent of the underlying monad. It doesn't even require the m in
ContT r m to be a
On Fri, May 14, 2010 at 4:25 PM, Derek Elkins derek.a.elk...@gmail.com wrote:
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT r (Either e). The bind implementation for ContT is completely
independent
On Fri, May 14, 2010 at 4:53 PM, Antoine Latter aslat...@gmail.com wrote:
On Fri, May 14, 2010 at 4:25 PM, Derek Elkins derek.a.elk...@gmail.com
wrote:
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT
Andrea Vezzosi wrote:
wren ng thornton wrote:
With this change [1] I can't notice any difference for your benchmark[2].
Then again, all the runTest calls take 0 msec and I've had no luck making
the computation take much time; perhaps your computer can detect a
difference.
On my machine, with
Antoine Latter wrote:
While I also offer a transformer version of MaybeCPS, the transformer *does*
suffer from significant slowdown. Also, for MaybeCPS it's better to leave
the handlers inline in client code rather than to abstract them out; that
helps to keep things concrete. So perhaps you
On Thu, May 13, 2010 at 10:51 AM, wren ng thornton w...@freegeek.org wrote:
Andrea Vezzosi wrote:
wren ng thornton wrote:
With this change [1] I can't notice any difference for your benchmark[2].
Then again, all the runTest calls take 0 msec and I've had no luck making
the computation take
Andrea Vezzosi wrote:
On Thu, May 13, 2010 at 10:51 AM, wren ng thornton w...@freegeek.org wrote:
Andrea Vezzosi wrote:
wren ng thornton wrote:
With this change [1] I can't notice any difference for your benchmark[2].
Then again, all the runTest calls take 0 msec and I've had no luck making
On Wed, May 12, 2010 at 7:50 AM, wren ng thornton w...@freegeek.org wrote:
wren ng thornton wrote:
Here's one big difference:
newtype ErrCPS e m a = ErrCPS { runErrCPS ::
forall r . (e - m r) -- error handler
- (a - m r) -- success handler
- m r }
The analogous version I use
On Tue, May 11, 2010 at 8:28 PM, wren ng thornton w...@freegeek.org wrote:
Max Cantor wrote:
Based on some discussions in #haskell, it seemed to be a consensus
that using a modified continuation monad for Error handling instead
of Eithers would be a significant optimization since it would
Max Cantor wrote:
Based on some discussions in #haskell, it seemed to be a consensus
that using a modified continuation monad for Error handling instead
of Eithers would be a significant optimization since it would
eliminate a lot of conditional branching (everytime = is called
in the Either
wren ng thornton wrote:
Here's one big difference:
newtype ErrCPS e m a = ErrCPS { runErrCPS ::
forall r . (e - m r) -- error handler
- (a - m r) -- success handler
- m r }
The analogous version I use is:
newtype MaybeCPS a = MaybeCPS
(forall r. (a - Maybe r) -
On Mon, May 10, 2010 at 5:38 AM, Max Cantor mxcan...@gmail.com wrote:
Based on some discussions in #haskell, it seemed to be a consensus that
using a modified continuation monad for Error handling instead of Eithers
would be a significant optimization since it would eliminate a lot of
Makes sense. From what you wrote, it seems like this might be a dead-end and
can't really be optimized away. Do you agree?
Max
On May 10, 2010, at 8:38 PM, Jan-Willem Maessen wrote:
On Mon, May 10, 2010 at 5:38 AM, Max Cantor mxcan...@gmail.com wrote:
Based on some discussions in
20 matches
Mail list logo
