Am Sa., 19. März 2022 um 20:58 Uhr schrieb Linas Vepstas
<xxxxxx@gmail.com>:

> I'd like scheme to be as-fast-as-possible, as what else is it offering the world? it's not going to be python or java or rust. It may as well be tight.

I think we can agree that we do not wish to standardize APIs in a way
that prevents efficient implementations. But "efficient" is a notion
relative to the abstraction we want to model in each particular case.
If we have a Scheme API that models something like pthread's
thread-local variables, we would want that it can be implemented
roughly as efficiently as the native C API. On the other hand, if the
more correct model for a certain use case would be dynamic state bound
to the current continuation, Scheme can offer an API for this
abstraction (parameter objects, the current parameterization, etc.)
that is not offered by C and which may more correct in some use case,
but slower than thread-local storage.

For an API like phtread's thread-local variables, we are presented
with different options for an API. One possible API could allow
general Scheme objects as keys to thread-local variables; another
possible API choice could be to restrict keys to opaque values
returned by some procedure, say, (thread-local-key). The latter API
can more likely directly map to the pthread API, and won't be less
efficient (up to a constant factor) than C; this may not be true for
the former API.

Marc