[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Write procedure is not backwards compatible
John Boyle scripsit:
> That doesn't seem to cover all use cases that the parameter does.
> Suppose a library exports multiple writing procedures that call "write",
> and a user wants to make one of them use write/shared, but the other
> use write/safe;
Quite right; you probably can't do better than a parameter in that case.
> or suppose a user wants to use the same procedure in two places in
> a program, and wants one of the uses to use write/safe and the other
> to use write/shared. I guess the user *could* perhaps re-import the
> library for the sole purpose of getting a version of the exported
> procedure that uses a different "write"; would that be a serious
> recommendation (or is that even possible)?
The two places in the program would need to be in two different libraries.
> (Also, is it easy for the user to change the structure of imports in
> a running program, without side-effects other than some function
> calls being redirected to the new "write"? I imagine someone
> using write/small-fast, finding an error, and wanting to switch to
> write/shared to diagnose the source of the circular input, then
> fixing the error and wanting to switch back to write/small-fast,
> without resetting any global state that his library might initialize.
> With parameters, this could be trivial.)
No, imports happen before run time, like macro expansions. To get that
behavior, you'd have to plan ahead of time by providing a variable that
points to the correct `write` procedure and then mutating this variable.
I am a member of a civilization. --David Brin
Scheme-reports mailing list