component-model icon indicating copy to clipboard operation
component-model copied to clipboard

First-class functions/closures as resources

Open badeend opened this issue 8 months ago • 4 comments

I was wandering, now that resources/ownership/borrowing/etc are properly part of the component model; In what way are closures not "just" single-method resources? Can they piggy back off of the semantics and restrictions defined for resources?


For example, given the imaginary interface (& syntax):

interface A {
	register-event-handler: func(handler: fn(event));
	map: func(items: list<string>, mapper: borrow<fn(string) -> string>) -> list<string>;
}

Assuming that the following resource types are (automatically?) defined somewhere

resource fn-event { // fn(event)
	call: func(a1: event);
}

resource fn-string-string { // fn(string) -> string
	call: func(a1: string) -> string;
}

how is the first example different than this:

interface A {
	register-event-handler: func(handler: fn-event);
		// Fn is passed as "owned" handle. Ie. it's the responsibility of the
		// implementation of `A` to properly drop the resource/closure.
		// On the flip side, `A` can call `handler` as much as it wants even
		// after `register-event-handler` has returned.

	map: func(items: list<string>, mapper: borrow<fn-string-string>) -> list<string>;
		// Fn is borrowed. Ie. `mapper` may only be called during the
		// invocation of `map`, and must be dropped before returning.
}

?


By (re/ab)using resource semantics, this would keep function "references" in the realm of acyclic dependencies a.k.a. "no global GC required", right?

badeend avatar Nov 29 '23 17:11 badeend