search

jnicklas / mini-effection

Experimental reimplementation of Effection in Typescript
4 stars 0 forks source link

Figure out how we can use `Iterator` instead of `Generator` #2

Open jnicklas opened 4 years ago

jnicklas commented 4 years ago

The throw and return methods are not mandatory on Iterator, so we need to figure out the proper semantics of what is supposed to happen if an iterator does not implement them.

cowboyd commented 4 years ago

If an iterator does not implement throw or return then that seems to imply that it has no internal state beyond a simple iteration pointer, and so we can provide implied default behaviors:

return: Given that, there is no state that could be cleaned up with a return() via a finally block, or that could alter the course of the iteration at runtime, it is safe to do nothing if no return function is present.

throw: By the same token, if no throw() method is present, we can assume that the iterator cannot handle the error, nor is there any state that must be cleaned up, and so we can simply raise the error to the parent operation.

In most cases, I'd expect iterators like this to represent a static list of operations [op1,op2,op3] that are not sensitive to runtime conditions, and so both of these conceptions of throw() and return() should work. In the event that there is some dynamicity that isn't a generator, then it would definitely be up to the custom iterator object to implement return() and throw() with the appropriate semantics. I must admit that it's hard to imagine a case where you would want to do this other than if you were implementing your own language interpreter.