On Fri, Aug 6, 2010 at 9:12 PM, Greg Ewing wrote:
I've been doing some more hacking, and I now have a working implementation of cofunctions, which I'll upload somewhere soon.
I have also translated my yield-from examples to use cofunctions. In the course of doing this, the additional restrictions that cofunctions impose have already proved their worth -- I forgot a cocall, and it clearly told me so and pointed out exactly where it had to go!
This is good to hear. Without being too critical, I feel like saying that so far I've been following the cofunctions threads and waiting for compelling use cases. So, I'll be happy to see what you have there. It seems like the main use case that comes to mind for cofunctions is, essentially, quick and dirty cooperative multitasking. Of course, as we all know on the OS side of things, cooperative multitasking has been more or less phased out (I don't know about the embeded space. Probably it's hanging on there for real time purposes.) in favor of preemptive multitasking. But Python already has preemptive multitasking: it's called threads. Or, if one prefers, there is multiprocessing. Of course, those are relatively heavy-weight, but then again, so is adding new keywords and syntax. So, other use cases would be appreciated.
I forgot a cocall, and it clearly told me so and pointed out exactly where it had to go!
Hmm. I think this can be pushed even farther. For example, we could use mandatory function annotations to mark what classes a function is capable of receiving and we could mark the classes of variable names using some new syntax. Then when, for example, you accidentally try to send a string to sum, you could be told at compile time "TypeError." I propose we call this "Static TypeErroring". ;-) OTOH, "Explicit is better than implicit." So, maybe the explicit syntax for cocalling is worth the pain. Again, I'd like to see more motivating examples. Cautiously-optimistically-yrs, -- Carl Johnson