Hi Roger, Glad you found this interesting, and thank you for reading !
One can obviously always use methods on a structure instead of coroutines (in the example I provided, the state could be stored in the tokenizer), and the question is when storing the state on the Go stack directly makes code more readable – and yes, a lot of what “readable” means is colored by one’s own experience. I think the largest benefit does not stem from the feedback from the parser to the tokeniser (although I do find it very cute), but instead from the ability of the parent routine to restart the parser when an error is found. With coroutines, this can be expressed as a simple for loop; but I have not seen something as neat with other methods – either stack unwinding (hard to maintain invariants) or instead pushing deep down in the parser the knowledge about how much tokens to throw away. My goal in reaching code currently hidden in the library was to see how much more we could do if we had full coroutines, and not making any claim about finding a “best” or even a “better” approach. Looking forward to seeing what you create with iterators! Best -- Romain -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAMYUV_oa_DEWceZUFx6EqPjkJ1cqVA5GS6pQEeK-h%3DkrExAhiA%40mail.gmail.com.
