Alistair's v0.3 feature requests

[apt1002]

A short list of requests for Ursa v0.3

• [X] obj.iterator() is the method invoked by the for syntax built in to Ursa. It should perhaps be iter() and should certainly not be restricted to objects.
• Unify generators and async functions. The hard part of each is to save the stack in a way that allows execution to be resumed later, so make a mechanism to do that (#15?). The differences can then be confined to a wrapper around that mechanism. I won't be unifying generators and async, at least in 0.3.
• Algebraic types (which I think you are calling "enums" and "match"). Algebraic types will support exceptions and error handling. I think you can do algebraic types and static type checking in either order. Relevant minutes from Welly: 1. #29.
• [ ] Static types. #28

[rrthomas]

Async is done; generators turn out to be hard. JavaScript already provides async, and I've already made ArkExp.eval async throughout, so adding async to Ursa was just a matter of selectively engaging or avoiding serialization of execution at certain points.

Meanwhile, JavaScript provides generators too, but I can't see how to use them without changing the structure of the Ark interpreter considerably. Currently, Ark uses exceptions to implement return, as each Ursa function call is represented by a stack of JavaScript function calls, because .eval() recurses into the Ark tree. There is no way in JavaScript to resume execution after an exception.

As far as I can tell, the only way to resume execution of a function in JavaScript is to use its generators. To use them for Ursa generators, I would either have to flatten the implementation of .eval() so that it does not make JavaScript function calls except to implement Ursa function calls; or, I would have to manually implement stack unwinding for return, continue and break, and use generators everywhere in the implementation of eval().

There are two options I can think of to implement Ursa generators without JavaScript generators:

1. Have a way to represent the state of an Ursa computation, including its stack and "program counter". The stack frame is already represented in an ArkState, and could be saved in the yield exception. But the "program counter" is currently encoded in the JavaScript stack, and encoding it explicitly would require Ark to be changed to make it possible to record the state of a partially constructed ArkVal, and the execution location within an ArkExp. This is tricky.
2. Replace the Ark interpreter with a JavaScript back-end. I was planning to rewrite the current prototype JavaScript backend anyway to translate Ark rather than Ursa directly (so that in future the Ark code can be transformed, as in a grown-up compiler, before target code is output), so this seems the sensible way to go. (This will still necessitate the workaround mentioned in #15 to implement general continuations.)

[rrthomas]

Retargeting algebraic types to version 0.4. See #29.