What is the intended way of expressing generator function interfaces in WIT?

[peter-facko]

• JS - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*
• Python - https://docs.python.org/3/glossary.html#term-generator

How should I express a function that produces values synchronously in WIT? Let's say in a situation where the whole sequence of produced items doesn't fit into memory.

[lukewagner]

Hi! Great question. With Preview 3 features, I believe the default way you'd do this is using:

value-generator func() -> stream<some-element-type>;`

[dicej]

I would expect this to be modeled as an async function which returns a stream<T> (where T is whatever type you want your generator to yield). The implementation would create a new stream<T>, pass the write end to a closure which will run post-return, and then return the read end.

EDIT: I didn't see Luke's reply when I wrote the above; sorry for the redundancy.

[peter-facko]

Hello! Thank you both for the reply.

Does this also hold for synchronous cases? I was aware of stream, but since it was always documented under async and concurrency labelled sections, I thought I should use it only when the generator is async.

And is it also true for functions returning a stream that the implementation can be sync or async, with the caller getting the same interface?

[lukewagner]

Although it depends on the bindings generator to expose this functionality, in general, you can use streams in both sync- and async-style code.

(After #578) The only difference between a func() -> stream<T> and async func() -> stream<T> is whether the callee can block before returning the readable end of the stream. Unless there is some domain-specific significance between issuing the function call and getting back the stream that you need to represent, I think by default interfaces would use func() -> stream<T> since a callee can always immediately stream.new a readable+writable stream end pair and task.return the readable end without needing to block on anything (and after task.returning, both sync and async functions can block all they want). There would be a difference between the two signatures to the caller's source bindings in that the func() -> stream<T> would, e.g. in JS, return a ReadableStream whereas the async func() -> stream<T> would return a Promise<ReadableStream>.

[peter-facko]

Thank you, I think this answers all my questions about generators.