jasondelaat
commented
3 years ago I've been playing with this a bit. There are a few problems with the implementation but I think there are problems with the concept of do-notation in Python more generally. I've made attempts at do-notation in the past and never been particularly satisfied with them. That said, I'm not actually against the idea so if we can find something that works I'll definitely consider it.
With that said, I'll walk you through the problems that I see so far:
First a minor issue. The old version of PyMonad had operators by default but they're very un-pythonic. I've kept them around in the operators sub-package but for general purpose stuff like your 'do' function it's best to stick to the 'bind' instead of '>>' since that will be available everywhere.
More problematic, this won't work as written for other monads. Consider Writer.
from pymonad.writer import Writer
@do
def log():
yield do_a(None)
yield do_a(None)
return do_b(None)
def do_a(_):
return Writer(None, 'Doing A, ')
def do_b(_):
return Writer(None, 'Doing B, ')
print(log())(None, Doing B, )Even though the functions don't do anything, I want the full log but this will only give me back the log from the last line of log(). Changing the return to a yield means I end up getting nothing back at all.
We can actually fix that and the recursion problem at the same time.
from pymonad.writer import Writer
def do(generator):
def new_func(*args, **kwargs):
gen = generator(*args, **kwargs)
val = next(gen)
while True:
try:
val = val.then(lambda x: gen.send(x))
except StopIteration:
return val
return new_func
@do
def log():
yield do_a(None)
yield do_a(None)
yield do_b(None)
def do_a(_):
return Writer(None, 'Doing A, ')
def do_b(_):
return Writer(None, 'Doing B, ')
print(log())(None, Doing A, Doing A, Doing B, )This gives us what we want but we have to ban 'return' from any coroutines that we use with do because using return will end up throwing away the log. A similar problem would happen with State, etc.
Except now that implementation of 'do' won't work with your original example. When we try to divide by zero we get back a Nothing (as expected). The next iteration of the loop then calls 'bind' on Nothing which simply ignores the function passed to it. As a result gen.send() is never called, we never raise StopIteration and we're stuck in an infinite loop.
There are a couple ways we can solve that but neither is ideal.
The first is that we can modify 'do' to check the type of the monad it's working with and if it's a Maybe (or Either) we treat it slightly differently. This is brittle though since any new monads, whether added to PyMonad directly or added by users, might also need special conditions and 'do' becomes a mess and stops being general.
The second solution isn't really a solution, it just looks like one in the right light.
def do(generator):
def new_func(*args, **kwargs):
gen = generator(*args, **kwargs)
val = next(gen)
next_val = val
while True:
try:
next_val = gen.send(val.value)
val = val.bind(lambda _: next_val)
except StopIteration as e:
return val
except:
return next_val
return new_funcBasically, we pull the gen.send() call out to get the next value and then we bind to a lambda, ignoring the input and returning the next_val. This works exactly the same for the logging example but it would actually fail for the Maybe example because we'd end up with 'divided' being assigned the value None and then attempting to add None and 10, raising a TypeError.
The example seems to work because the final catch-all except clause catches the TypeError and "backs up" to the last valid value and returns that instead. In your example that happens to be Nothing and so we seem to get the correct behaviour. And this is why it's not really a solution. Suppose we do something like this to the log example:
@do
def log():
yield do_a(None)
yield do_a(None)
x = None + 10
yield do_b(None)(None, Doing A, )That's an actual error that needs to be fixed but the program appears to work fine. In actual fact we're getting a truncated log and masking an error, not unlike the problem with Maybe in Issue #1.
ckp95
jleonard-r7
MichaelSchneeberger
With coroutines we can implement a Haskell-ish do-notation. Call them "doroutines":
We yield monad values out of the coroutine, and get unwrapped values back. The decorator handles the bookkeeping logic. Here's a rough implementation:
The main deficiency here is that we are limited by the Python interpreter's maximum recursion depth of about 1000. I tried to convert it to an iteration but it gave me a headache since we're returning a function each time rather than a value :S.
It currently relies on the generator raising a
StopIterationexception to get the return value, which is incompatible with theEithermonad which is supposed to capture exceptions and halt their journey up the stack. I see two ways of dealing with this: first, keep thedoimplementation the same and have theEithermonad log all exceptions other thanStopIteration; second, create some kind of wrapper/decorator for generators so that they use anEithermonad to signal their return value instead of an exception, then alterdoso that it exits when it sees this type of error. I think the second one is preferable.I've only tested it with
Maybeso far. I had to editMaybeso that it doesn't swallow errors as I mentioned in #1. For that I just commented out some parts in themaybe.pyfile:I'm not familiar enough with the codebase to figure out a more robust solution yet.