Carl Mäsak

> Only quibble I have is on the macro implementation: if object_ast is something that performs a destructive operation (say, getting the next item off a queue or something), wouldn't...

> Oh, another thing. In ST `invocant m1; m2; m3` has the return value of `m3`, not the invocant itself which is what we get with this macro. Hm, you're...

Smalltalk's syntax is different than the one I propose in OP. It uses [semicolons and periods](https://github.com/sl4m/gnu_smalltalk_koans/blob/92a186f6be5226498c1f9deec4ab36e6be4f6dd5/src/koans/TestArray.st#L32-L36). I think I might have gotten the `..` syntax from [LiveScript cascades](http://livescript.net/#property-access-cascades). Who knows...

> - The implementation of `next` would then be `if loopcondition { ctrlflow.goto(findtag("loop").beginning); } else { ctrlflow.goto(findtag("loop").end); }` I'm subtly and dangerously wrong above. A `next` is _not_ a simple...

Note that, even if we make the feature totally static and lexical, we will still have interaction between `next` et al. and the call stack: ``` for [1, 2, 3]...

Coming back to this issue and re-reading it, I say we might consider going the Python route and forbidding `next` et al. if there's a layer of `sub` between the...

This issue is bounded above in an interesting way by #166 and similar. When we compile to a different backend, we can no longer do very exotic things with the...

> When we compile to a different backend, we can no longer do very exotic things with the control flow. But (as I come back to this later and re-read...

Been thinking lately about how `return` interacts with `catch` and #156, and how that needs to be exposed in some sensible way. Essentially, `return` doesn't really mean "return immediately" in...

Quite a bit of overlap here with #252 which I just filed.