These are chat archives for evhub/coconut
returnis ugly and shouldn't exist, but the fact is that it exists in Python, so I can't get rid of it if I want to maintain all valid Python syntax. Thus, wherever I allow a function to return something without using
return, I introduce inconsistency into the language. That's okay if there's a really good reason for it, but the reasons for shorthand function notation as it exists right now are both specific to short functions. Specifically, the reasons I had were:
def f(x) = y, because that is math-like, but not for
since that isn't math-like at all.
def new_assign(foo) = if foo == 0: "Zero" elif foo == 1: "One" else: "Dunno"
return). (And lambdas are insufficient for this purpose because they can't be named in tracebacks or be pickled for use in multiple processes.)
returnin a complex function is convenient for the person writing the code, and is a much more elegant way to write a function, but I worry that it introduces unnecessary inconsistency that someone reading the code is going to have to deal with. If I'm reading some Coconut, and I see a big function, I don't want to have to jump back up to the beginning of the function to see if it had an
:to figure out whether a line is going to be returned or not. I want to know just by looking at that line, and that's what
returndoes. Arguably, like I said above, the best approach would be to always return the last line and then
returnwouldn't be necessary, but I can't do that because I want to maintain all valid Python syntax.
returnor shorthand function notation (using
=, like in your example). That's just because TCO is kinda worthless if the function doesn't return anything.
--strictto resolve the ambiguity.
([x, y, z]) -> x + y > zresulting in ParseError, but
def ([x, y, z]) -> x + y > zworking, is expected behavior? If so, it would be nice to have this info in documentation.