The rationale claims that "It may [be] the
intention of the user that the message is printed to whatever
error port was current when the procedure error-handler
was defined" and suggests the following solution:
(define error-handler
(closed-lambda (msg)
(display msg (current-error-port))
(newline (current-error-port))
'error))
however, this effect can be achieved using the means
that are already present in the language:
(define error-handler
(let ((error-port (current-error-port)))
(lambda (msg)
(display msg error-port)
(newline error-port)
'error)))
While I don't deny that the interface proposed by the SRFI can be useful,
I think that presenting a problem that has a straightforward solution
is confusing and harmful to the presentation.
While this particular problem has a straightforward solution without ‘closed-lambda’, I don't think this makes the example necessarily confusing or harmful. The example I gave is just a minimal example that demonstrates what ‘closed-lambda’ does.
Nevertheless, I think you are right that I could add a few comments:
- More than one parameter object may be accessed in the dynamic extent of the body of the ’closed-lambda’. In that case, one would have to take not only a "snapshot" of, say, ‘current-error-port’, but of a many parameter object (and these have to be known). The resulting code, while working, is neither elegant nor nice nor Scheme-like.
- In the presence of SRFI 39 parameter objects that are mutable the technique of taking a snapshot of the current value won't work. (Imagine two ’closed-lambda’ procedures communicating via such a mutable paramter object.)
- The dynamic extent can be more complicated than just about parameter objects. For example, there could be global variables that are setup and restored by ‘dynamic-wind’.
--
Marc
To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=AR67FkMcUwd3BgWrS2KvXlvtKOubWJXD