These are chat archives for evhub/coconut

18th
Jan 2017
Eric Anderson
@Nexus6
Jan 18 2017 01:41
@evhub I see what you mean there w/addpattern, but that's a hugely simple example. I'm thinking of code where the last executed statement is deep in some conditional logic, maybe inside a pattern-match block, maybe a try/except/finally block. As for return, that's perhaps a personal thing, something I'm used to from Scala and CoffeeScript and others are probably used to from Ruby and other modern languages. Every line with a 'return' is a line that could have been put to good use for civilization. Functions without returns are also closer in appearance to mathematical notation. i.e. you write f(Z) = 2xZ not f(Z) = return 2xZ . "return" is a procedural artifact. It's been a while but IIRC Coconut requires the use of 'return' for TCO to work, no? I was wondering why that was.
Evan Hubinger
@evhub
Jan 18 2017 02:13
@Nexus6 I agree that return is 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:
  1. To add a math-like function definition syntax (like you said above). This argument makes sense for def f(x) = y, because that is math-like, but not for
    def new_assign(foo) = 
     if foo == 0:
         "Zero"
     elif foo == 1:
         "One"
     else:
         "Dunno"
    since that isn't math-like at all.
  2. Functional programming often involves making a lot of little functions. Thus, there should be a way to define small functions with a minimum of boiler-plate (like return). (And lambdas are insufficient for this purpose because they can't be named in tracebacks or be pickled for use in multiple processes.)
I get that dropping return in 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 = or a : 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 return does. Arguably, like I said above, the best approach would be to always return the last line and then return wouldn't be necessary, but I can't do that because I want to maintain all valid Python syntax.
Evan Hubinger
@evhub
Jan 18 2017 02:19
Also, TCO requires either return or shorthand function notation (using =, like in your example). That's just because TCO is kinda worthless if the function doesn't return anything.
Eric Anderson
@Nexus6
Jan 18 2017 02:23
@evhub re: return/no-return confusion ... you could have -s rage and scream about any return statement found in a .coco file. It complains about much more minor things that you might find infecting any ordinary Python source. In other words lots of ordinary Python isn't "strict" coconut. Coconut with returns could be seen as a violation of strictness too. So you'd get consistency, at least if you're being strict about it.
Evan Hubinger
@evhub
Jan 18 2017 02:24
@Nexus6 That's a great idea! I like that solution a lot, actually.
Eric Anderson
@Nexus6
Jan 18 2017 02:26
@evhub FWIW even though I'm belaboring it here I'm not totally hung up on the 'return' thing even if a puppy does die every time you use it. I'm pretty delighted to have the short return-less functions.
Evan Hubinger
@evhub
Jan 18 2017 02:27
@Nexus6 Thanks! And I just added a note to #190 about using --strict to resolve the ambiguity.
Eric Anderson
@Nexus6
Jan 18 2017 02:37
@evhub You'll have to add a discussion about that to your excellent documentation. Related to the filter/map/reverse thing .. right now reversed() in python (and Coconut) returns a "reversed" iterator which cannot be fed into functions like len(). Are you going to have reversed() return one of your own objects that has a length attribute, as you're doing with map/filter?
Evan Hubinger
@evhub
Jan 18 2017 02:49
@Nexus6 That's an excellent idea! I just raised #208 to track it.
Eric Anderson
@Nexus6
Jan 18 2017 03:16
@evhub Cool between that (the reversed object) and your filter fix I think you've solved @Slepice1 's problem.
@evhub Might as well give enumerate() the treatment as well. Any other built-ins that would benefit from the same tweak?
Evan Hubinger
@evhub
Jan 18 2017 03:38
@Nexus6 Just added enumerate to #208.
Eric Anderson
@Nexus6
Jan 18 2017 03:53
@evhub I did a quick scan of the other built-ins in Py and didn't see any others that would benefit from the #208 tweaks. But I don't see lots of things, maybe you will.
Vojtěch Jelínek
@vojtechjelinek
Jan 18 2017 15:34
@evhub Thanks, I thought that the problem was with using native python filter object.
Vojtěch Jelínek
@vojtechjelinek
Jan 18 2017 16:02
Another question, ([x, y, z]) -> x + y > z resulting 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.