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

From: R. Kent Dybvig <dyb>
Date: Wed Feb 21 10:09:30 2007

> What's the four-argument version of `dynamic-wind'?

Oops, sorry. The #t argument tells dynamic-wind to execute the in and out
thunk invocations uninteruptably along with their addition to or removal
from the winders list, which makes the code more robust if interrupts
(like keyboard or timer interrupts) can occur. I should have left it out
of the version I posted.

> > Anyway, didn't you just complain that parameters are too general?
>
> Yes. So?

So you directly contradicted yourself from one note to the next.

> >> Moreover, the particular design you chose is problematic because it
> >> destroys modularity.
> >
> > You've offered no evidence to this effect here or in your Scheme workshop
> > paper, which does not anticipate the design.
>
> The paper doesn't anticipate anything. The authors did, however. If
> I understand the semantics of Chez's parameters with respect correctly
> (I probably still don't), then the scenario section 5.3 of the paper
> applies. If it doesn't, I hope you'll enlighten me.

I've read that section several times without getting much out of it, but
nothing I see there applies to the parameter mechanism.

> Mutation is insidious in that, operating
> behind the scenes, it breaks through abstractions. Take the (r6rs
> mutable-pairs) library: Abstracting over it is not enough to get the
> benefits of its absence.

Abstracting would be sufficient, but mutable pairs are so pervasive that
doing so is impractical. For the programmer to replace mutable pairs with
their own immutable pairs, the programmer would have to recode all of the
library primitives that accept list or pair arguments, lambda, the reader,
and the printer. To replace parameters with your restricted construct,
one need only define your value-binding construct in terms of parameters
and use it in place of parameters.

Mutable pairs also affect efficiency in a pervasive manner; to eliminate
this one would have to rewrite parts of the compiler and storage manager.
There's no such pervasive efficiency problem here, and if there were, one
would have to eliminate the constructs parameters are defined in terms of,
e.g., set! and dynamic-wind, as well as parameters to get any benefit
beyond that derived by definining your value-binding construct in terms of
parameterize.

> I'm still unsure of the semantics of Chez's `parameterize'
> wrt. threads, so I'll probably get it wrong at first try. Here's it,
> in terms of your code:

Forget about threads then and just define a version that works in the
degenerate case of a single-threaded system.

> (define make-parameter
> (case-lambda
> [(init guard)
> (let ([v (make-thread-cell (guard init))])
> (case-lambda
> [() v]
> [(u) (thread-cell-set! v (guard u))]))]
> [(init) (make-parameter init values)]))

Okay, but where's the definition of parameterize in terms of your dynamic
binding construct? It didn't make it into your note.

Kent
Received on Wed Feb 21 2007 - 10:08:52 UTC