[r6rs-discuss] [Formal] SRFI-39 should be made an R6RS library
R. Kent Dybvig
dyb at cs.indiana.edu
Mon Feb 19 15:55:53 EST 2007
> No, it wouldn't, because if I link to somebody else's code that uses
> mutation behind the scenes, modularity is lost.
In other words, Mike really does want to deny Kent the right to do what he
wants. (Of course, Kent also wants to deny Mike the right to deny Kent
the right to do what he wants.)
> Here's a countersuggestion: We adopt a simple API than SRFI 39 with an
> opaque representation for parameters, without mutation. It could be
> just like SRFI 39, with the exception that dereference gets its own
> (parameter-ref param)
> retrieves the value of param.
This destroys one of the nice, simple properties of parameters, which is
that they are simply procedures and can be created by any means, not just
via make-parameter. This means that the encapsulated location can be just
about anything---a memory-mapped device address, a file, a screen image,
an environment variable, etc.
> Mutation can then be specified via (probably several different) SRFIs,
> and/or you can implement a Chez-specific extension which gives you
> what you want.
But not in portable code.
A better solution is for you to avoid using my code, because if I need to
modify a parameter, I'll find a way to do it, and it will be even harder
for you to understand than if you let me have a direct mechanism. That's
the way it goes with most restrictions.
More information about the r6rs-discuss