Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Python is where I developed my (naturally flawed but possibly useful) mental model for generators: you are "pulling" data out of them.

Instead of pushing data into a processing grinder, watching the sausage links pour out the other side, whether you're prepared or not, you're pulling each sausage on-demand, causing the machine to move as a consequence of wanting an output.

I'm sure smarter people appreciate generators more than I do. They're useful for co-routines and other wizardry. But I personally just find the mental model more useful in some cases, especially knowing it keeps memory and CPU usage more in-line with my needs. Doubly especially if my generator may not have an upper bound.

View on HN

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.

I honestly think the opposite.

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!

[0] https://hacks.mozilla.org/2015/05/es6-in-depth-generators/

[1] https://hacks.mozilla.org/2015/05/es6-in-depth-generators/#c...

This kind of thing shows up around several other related PL features, so much so that it has a name: https://wiki.c2.com/?SpaghettiStack

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.)

The mathematical definition of function also rejects all side-effects, so probably not the best thing to use around programming.

Call it a routine instead?

We had a descriptive yet very generic term for function-like stuff: "subprogram".

Oh man that brings memories: gosub in basic (though I think it was subroutine). Also Pascal had procedures vs functions.

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".

For a low level language having a proper mental model is important. Suppose you need to inspect the generated assembly.

Anyone care to explain their downvotes?

FWIW I'm really appreciating your comments. These are all models. I really enjoy hearing how others perceive things.

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).

This was killing me when back when I was a Python dev. A "generator" is just a callable object made less reasonable.

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.

I mean, if we're talking python here, functions are callable objects.

Good point.

Functions are objects too.

Reply on news.ycombinator.com