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.

--
John Cowan
        cowan@ccil.org
                I am a member of a civilization. --David Brin

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports