5 ms·

Async def are not colored functions in python. In fact there are not function at all, just like generators are not. Also coroutines can be called from functio

Async def are not colored functions in python. In fact there are not function at all, just like generators are not. Also coroutines can be called from functions and vice versa. You don't have to choose. The problem is not the color. The problem is the default paradigm is to be blocking I/O, and you add non blocking on top. It's way easier to make everything non blocking, then add blocking things on top. It's not a matter of syntax, but of core paradigm. Go and erlang were designed from the non blocking perspective from the get go. But even go add to use something to manage async control flow, so it uses channels, which you don't need if you have coroutines. Erland went deeper and made everything immutable, and baked in actors in the runtime. To me that's more impressive.

anonymoushn 6y ago
Can you expand on your notion of what is and is not a colored function? I might use this test: When I wish to add a call to a function that yields control other than by returning to the middle of a regular function, so that the latter portion of the regular function can use the results of yielding, do I then have to change the function declaration and every single call site? You clearly disagree. What test should we use?
- BiteCode_dev 6y ago
  It's like calling classes colored functions because you can both call them. Classes are not functions. They are classes. Coroutines are not functions, they are coroutines. Different primitives. A function has a single exit entry point and a single exit point and no state. If you call a function, you run its body. A coroutine has several entry points and exit points, and an internal state. If you call a coroutine, you make an instanciation (the body doesn't run). You can argue than using coroutine for async handling has drawbacks, but colored functions is not the proper analogy and make people very confused about the whole thing. The fact the syntax to define them is so similar doesn't help, and I see most people difficulties comming from their attempt to reconciliate models that have no reason to be. Just like a hashmap and an array are 2 different things despite you can index both, functions and coroutines must be understood as separated concepts.
  - anonymoushn 6y ago
    Alright. One reason for my confusion is that I assumed you would post "async functions (and generators?) are not colored functions in JavaScript" at the top level if you meant that, since the article is about async functions in JavaScript. So I wondered, what's the distinction between async functions in JavaScript and in Python that makes one "colored functions" but not the other? But this is not what you intended. Thanks for the clarification. Some programming languages have stackless async functions and generators that work the way you said, and some other languages have stackful coroutines. In the languages I use the most, functions that switch to other parts of the program are functions (according to the type system and the calling convention, but not in the sense that they have only one entry point and one exit point and no state). This is pretty great, because things are composable in precisely the way the article complains that they are not. Given that these things exist, it's fine to say "coroutines and functions are two different things" but maybe saying "a function which jumps to a different stack and which can then be jumped back into is not a function" will just make people very confused about the whole thing. If you have this, uh, code fragment: function read_five(socket) local data, err = socket:recv(5) if not err then return data end return nil, err end perhaps we shouldn't say "the value declared by the code fragment is a function or is not a function depending on whether recv nonlocally switches only to the kernel or whether it can also switch to an event loop in the same process"
  - Dylan16807 6y ago
    > A function has a single exit entry point and a single exit point and no state. If you call a function, you run its body. > A coroutine has several entry points and exit points, and an internal state. If you call a coroutine, you make an instanciation (the body doesn't run). Sort of, in some languages, but it doesn't have to work that way. First, let's note that "blues" do have state, and they put it on the stack. So blues can only be entered once and store state on the stack. Reds store state in an object, and they can yield out of the middle and be reentered. Then let's note that our top-level code has to be "red", or it would be impossible to ever run "red" code. Now let's go on a journey. 1. Make it so calling a red from a red will start running the body right away, by default. 2. When calling a red from a red and running the body, we're already inside a coroutine instance. Instead of making a new one, keep using the same one. Grow it and store the new state at the end. 3. When calling a blue, if we're inside a coroutine instance, put the blue's stack inside it. And since our top-level code is red, the we always are inside a coroutine instance. 4. Since all our stack frames are safely stored inside coroutine instances, it's safe to call from a blue into a red! The entire stack can be saved for later, blue and red alike. 5. At this point the only difference between blue and red is that a blue function cannot yield, it can only have something deeper on the stack yield. For fun, you could make 'yield' into a runtime-provided function. Now functions written in the language are all the same. There is no difference between blue and red. - So there is still a distinction between "coroutines" and "functions". But in this setup, a coroutine is merely a container that you run functions inside of. There is only one kind of code you run, and it is a function. Some language work this way. I wish javascript worked this way.

anonymoushn 6y ago

Can you expand on your notion of what is and is not a colored function? I might use this test: When I wish to add a call to a function that yields control other than by returning to the middle of a regular function, so that the latter portion of the regular function can use the results of yielding, do I then have to change the function declaration and every single call site? You clearly disagree. What test should we use?

BiteCode_dev 6y ago
It's like calling classes colored functions because you can both call them. Classes are not functions. They are classes. Coroutines are not functions, they are coroutines. Different primitives. A function has a single exit entry point and a single exit point and no state. If you call a function, you run its body. A coroutine has several entry points and exit points, and an internal state. If you call a coroutine, you make an instanciation (the body doesn't run). You can argue than using coroutine for async handling has drawbacks, but colored functions is not the proper analogy and make people very confused about the whole thing. The fact the syntax to define them is so similar doesn't help, and I see most people difficulties comming from their attempt to reconciliate models that have no reason to be. Just like a hashmap and an array are 2 different things despite you can index both, functions and coroutines must be understood as separated concepts.
- anonymoushn 6y ago
  Alright. One reason for my confusion is that I assumed you would post "async functions (and generators?) are not colored functions in JavaScript" at the top level if you meant that, since the article is about async functions in JavaScript. So I wondered, what's the distinction between async functions in JavaScript and in Python that makes one "colored functions" but not the other? But this is not what you intended. Thanks for the clarification. Some programming languages have stackless async functions and generators that work the way you said, and some other languages have stackful coroutines. In the languages I use the most, functions that switch to other parts of the program are functions (according to the type system and the calling convention, but not in the sense that they have only one entry point and one exit point and no state). This is pretty great, because things are composable in precisely the way the article complains that they are not. Given that these things exist, it's fine to say "coroutines and functions are two different things" but maybe saying "a function which jumps to a different stack and which can then be jumped back into is not a function" will just make people very confused about the whole thing. If you have this, uh, code fragment: function read_five(socket) local data, err = socket:recv(5) if not err then return data end return nil, err end perhaps we shouldn't say "the value declared by the code fragment is a function or is not a function depending on whether recv nonlocally switches only to the kernel or whether it can also switch to an event loop in the same process"
- Dylan16807 6y ago
  > A function has a single exit entry point and a single exit point and no state. If you call a function, you run its body. > A coroutine has several entry points and exit points, and an internal state. If you call a coroutine, you make an instanciation (the body doesn't run). Sort of, in some languages, but it doesn't have to work that way. First, let's note that "blues" do have state, and they put it on the stack. So blues can only be entered once and store state on the stack. Reds store state in an object, and they can yield out of the middle and be reentered. Then let's note that our top-level code has to be "red", or it would be impossible to ever run "red" code. Now let's go on a journey. 1. Make it so calling a red from a red will start running the body right away, by default. 2. When calling a red from a red and running the body, we're already inside a coroutine instance. Instead of making a new one, keep using the same one. Grow it and store the new state at the end. 3. When calling a blue, if we're inside a coroutine instance, put the blue's stack inside it. And since our top-level code is red, the we always are inside a coroutine instance. 4. Since all our stack frames are safely stored inside coroutine instances, it's safe to call from a blue into a red! The entire stack can be saved for later, blue and red alike. 5. At this point the only difference between blue and red is that a blue function cannot yield, it can only have something deeper on the stack yield. For fun, you could make 'yield' into a runtime-provided function. Now functions written in the language are all the same. There is no difference between blue and red. - So there is still a distinction between "coroutines" and "functions". But in this setup, a coroutine is merely a container that you run functions inside of. There is only one kind of code you run, and it is a function. Some language work this way. I wish javascript worked this way.