feat: call accepts plain functions

[neurosnap]

Motivation

As library developers, we might want to require the user to understand delimited continuations or any of the constructs created by effection. Sometimes we want to let the end-user provide anything reasonable we call() knows how to reflect what was passed into the function and it will handle it automatically. The most obvious example is Promise. We don't have to require the user to convert a Promise into an Operation.

Being able to pass a vanilla function into call() would also be nice since it is trivial for us to detect and accept.

So in summary, we want to support the following variables to call():

call(() => thing);
call(async () => thing);
call(function*() {});

Approach

We try to inspect the type of the variables passed into call() and figure out how to evaluate it.

[cowboyd]

Why might this return an Operation<Iterable>? If you have call(() => []) which override will it select? The one on line 68 or 69?

[neurosnap]

You're right, removed. Probably old code from when I was experimenting.

[cowboyd]

I think this is the best option we have. As noted, there is a small discrepancy in the types and the runtime behavior in the event that you call(() => instructions) where instructions is an array of Instruction.

This is a very tiny edge case.

The only remaining decision is whether to support bare values. In other words, should callable be:

| (() => T))
| (() => Promise<T>))
| (() => Operation<T>))

or

| T
| Operation<T>
| Promise<T>
| (() => T))
| (() => Promise<T>))
| (() => Operation<T>))

It feels like we should support one or the other, but not somewhere in between.

[cowboyd]

Can we use guards where possible? It saves a little casting when you use them.

Suggested change

	function isPromise(p: unknown): boolean {
	if (!p) return false;
	return isFunc((p as PromiseLike<unknown>).then);
	}
	function isPromise<T>(p: unknown): p is Promise<T> {
	if (!p) return false;
	return isFunc((p as Promise<T>).then);
	}

[cowboyd]

Since we can't get rid of lift, let's continue to use it here. We can revisit the best way to do this later, but lift is not going to create a frame which is preferable.

[cowboyd]

I wouldn't call this a string iterator, but just a function returning a string.

[cowboyd]

Shouldn't this be Iterator<Instruction, T>?

[cowboyd]

Can we move these private functions to the bottom of the file and lead with the implementation of call()?

[cowboyd]

Looks like there's a slight grammatical error here. Might as well fix this now.

Suggested change

	* Pause the current operation, and run a promises, async functions, or
	* operations within a new scope. The calling operation will resumed (or errored)
	* Pause the current operation, and run a promise, async function, or
	* operation within a new scope. The calling operation will resumed (or errored)

[cowboyd]

Looks good!