[External] : Re: Scope Locals
John Rose
john.r.rose at oracle.com
Thu Apr 1 01:44:21 UTC 2021
Thanks for the detailed replies. We are on the same page.
On Mar 31, 2021, at 3:10 AM, Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>> wrote:
OK, that means you can’t say this:
var slink = ScopeLocal.set(x, xinitval).set(y, yinitval);
var xval = slink.get(x);
var yval = slink.get(y);
Right. Bindings can only be used inside an in() expression.
But you could say this:
var xval = slink.in(x::get);
Also right.
So is there any gain from disallowing the previous API
usages?
I'm not quite sure what you mean by "the previous API usages.”
I mean that if slink.in(x::get) is allowed then
slink.get(x) could be sugar for exactly that.
And it would be more directly optimizable.
(Why do it? Well, you are writing configuration
setup code that is tweaking a “slink” chain of
bindings, getting ready to put them into use.
So slink.get is the natural companion to slink.with.)
Basically, I’m looking sideways at “slinks” as if
they are of this type:
interface ScopeLocalMap /*no type-var*/ {
// configuration:
<X> ScopeLocalMap with(ScopeLocal<X> key, X val);
<X> X get(ScopeLocal<X> key);
// execution:
<T> T execute(Supplier<T> body);
}
as well as:
interface ScopeLocal<X>
//?? implements Supplier<X>
{
X get();
}
More information about the loom-dev
mailing list