"That's what I did with (stderr:stdout). Calling 'stderr with an argument sets (stderr) to that value permanently (or somewhat permanently, depending on whether other code also mucks around with 'stderr)."
Huh, I didn't know that.
---
"If you replace them with regular global variables, it's probably a good idea to implement those particular variables using threading.local() somehow, just so one thread's (w/stdout ...) doesn't mess up any other threads."
Right, threads. I hadn't given any thought to them (they're not implemented yet, either). I'll have to revisit this issue later, when I actually implement threads.
---
"By the way, (coerce (stdin) 'byte) doesn't seem like a good way to read bytes if Unicode's on the scene."
Hm... I guess it depends on what you expect it to return. If it's a Unicode character that can be represented as a single byte (in UTF-8), then just returning that should be fine. Trickier if the code point is represented as more than one byte, but wouldn't that still be possible, assuming code would be expecting multiple bytes? Of course then there's the old fallback of (readb) or (stdin 'byte).
---
"Implement them explicitly in the language core, for instance by calling everything in CPS or by maintaining explicit call stacks. This lets you implement continuations that have exactly the features you want, rather than just the features that come naturally from the platform."
I was leaning toward that approach (everything CPS), but I'm still mulling it over. Python doesn't have TCO, though, so wouldn't CPS exceed the recursion limit in Python, unless I implement a trampoline? In which case things will get even slower, hurrah.
