I mean that's fine but the language decision that makes my small brain break is "why call it a function, instead of calling it a completely different name to represent the completely different things that it is"?
I never thought of that, and now I'm asking the same question.
Perhaps there's history or mathematical explanations to this. But, yeah, "A function that can temporarily pause itself and be returned to later" is a possibly confusing overloading of the concept of a function.
When I learned generators from
Python the understanding of “a function that yields instead of returns” was very easy to grasp. And considering I already knew how functions worked & what their syntax was this was just an extra step (rather than starting from scratch). ECMAscript have taken a similar path to Python here.
This could also be because my mental model is they are just functions that have the ability to return to the stack at a later point in time, rather than “running to completion”.
Yup, I can see that! One issue I have is that my model of the stack is that "it's a literal _stack_ of frames. You pop them one by one, executing them."
What happens to a frame that you pause? Does it get set aside? Is it still on the stack?
This article[0] and a clarifying comment[1] answer the question for JS. I think it's the same for Python. Apparently your model (which was mine, too) is out of date!
Well maybe it's my small brain but I remember in math class it was very important that "a function has only one return value", which probably is part of why I was confused.
Technically generators still only have one return value: an Iterable. That Iterable represents an object with a "next()" callback and you can entirely write by hand Iterables as simple dumb objects if you like. (The generator function syntax makes it a lot easier to build complex state machines, but most languages aren't going to stop you if you prefer to write your state machine by hand.)
It makes sense in a low level language like zig, because an async functions there truly is a function frame (in the sense of set up a stack and save your registers to be popped off of it at the end) but in high level languages - and even rust, if my understanding of how async works in rust - it's different and calling it a function seems incorrect.
Why do you care what it "truly" is under the hood? The observable behavior is what matters, and in many languages, this is made explicit by some kind of "as-if rule".
Yep. The only way I've ever been able to understand generator/coroutine-based code is by desugaring it into iteratees into my head. (Before I learned about iteratees, I simply couldn't understand them at all).
Even callable objects are kinda brain breaking. I used to joke that the duality of callable objects (and getter/setters, function prototypes in js) were as mysterious as the wave/particle duality in quantum mechanics.
