New candidate JEP: 429: Extent-Local Variables (Incubator)

[John Rose]

I’m very glad to see this moving towards completion.
Better threads richly deserve better thread locals!

I’d like to check my understanding of the intermediate
type `Carrier`.  Is it the case that the information content
of a carrier made by `c=ExtentLocal.where(k,v)` is just exactly
the pair `k,v`?  And then, after that, I suppose a carrier made
by `c.where(k2,v2)` contains exactly `k,v,k2,v2`.  (But if
`k==k2` then the information content is just `k2,v2`.)

And if that is true, then I can store a `Carrier` in a global
variable, even pass it to five other threads, and have each
of them call `c.run(…)` with completely independent sets of
bindings, except for the `k,v,k2,v2` mandated by the carrier’s
information content.

What I’m trying to exclude here is that a `Carrier` somehow
threads in the ambient binding map for the current extent,
as non-locally defined by all of the caller frames, plus
whatever bindings might have been provided when the current
thread was launched.

IIRC you have chosen not to provide general methods for working
with binding maps.  (There is no key/value iterator on `Carrier`.)
And then reifying the very special binding map in the current
extent is right out.  I think this is fine, although maybe use
cases will eventually call for map-like views on both local
carrier multi-tuples and grand non-local binding maps.  Those
can be added later if needed.

So, my asking to confirm the very finite and local information
content of the type `Carrier` is really me double-checking
that no larger binding-map API sneaks through the current JEP
API.

A very different design would sneak in an reified map pointer
into every result of `c=ExtentLocal.where(k,v)` such that
bindings available in `c.run(…)` would come only from c
and its uplevel pointer, completely blocking any bindings
present at the call to `c.run`.  I guess such bindings would
no longer be properly called “extent-local”; only the binding
map root would be extent local but it would be subject to
radical editing on each call to `c.run(…)`.

Make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220816/884cc667/attachment-0001.htm>