[r6rs-discuss] [Formal] SRFI-39 should be made an R6RS library

From: R. Kent Dybvig <dyb>
Date: Sun Feb 18 11:59:00 2007

> So, maybe it's just me, but you see I'm having trouble understanding
> the subtleties of the Chez model for parameters.

I think it would have been easier for you had you accepted my original
statement that Chez Scheme's model has the semantics you seem to want as
long as mutation isn't involved. You could have answered most if not all
of your subsequent questions by referring back to that statement.

There's actually nothing subtle about the model. Parameterize works just
as advertised---the same in a threaded setting as in a nonthreaded
setting---and thread parameters modify or read the current thread's
storage location. I'm sure one can write subtle programs using the model,
but that's true with any of our building blocks.

> On the other hand, dynamic binding without mutation thrown in has very
> simple semantics and arguably covers most of what's important about SRFI
> 39.

I don't think it does. It's not uncommon for me to change parameters
directly.

> Thread-local storage is also useful and has reasonably simple
> semantics, but, in my experience, needed much less frequently. (In
> Scheme 48, the necessity arises to infrequently that we just stick the
> handful of thread-local values into the thread data structure itself.)

That's where they are stored in Chez Scheme as well, in an extensible part
of the data structure so that applications can create their own
thread-local storage. Surely your set is also extensible, unless you've
somehow managed to anticipate all possible application needs for
thread-local storage.

> If both are implemented, it should at least be up to the user how to
> combine them.

I don't believe that this would give me what I want if we adopt your
value-only dynamic binding, but I have a different suggestion that should
give both of us what we want: We adopt SRFI 39 now and generalize to
threads later by having make-parameter do what Chez Scheme's
make-thread-parameter currently does.

With this proposal, Mike can choose by convention (possibly enforced by an
abstraction layer) never to change directly the parameters he
parameterizes, giving him the separate thread-local storage and dynamic
binding semantics he wants, even after we add threads. Meanwhile, Kent
can ignore Mike's convention and get the more general semantics he wants.
Mike and Kent both get what they want, except in the sense that Mike is
denied the right to prevent Kent from doing what he wants.

Kent
Received on Sun Feb 18 2007 - 11:58:48 UTC