On Mar 8, 2020, at 10:56 AM, John Cowan cowan@ccil.org wrote:
On Sun, Mar 8, 2020 at 10:44 AM Adam adam.mlmb@gmail.com wrote:
Parameter objects are very practical and have ample use scenarios, both high-level and relatively low-level.
I would be interested in hearing about these use cases. In particular, parameters (unlike fluid/dynamic variables) are first-class: they can be stored in local variables or data structures. If you have any use cases of this kind, I very much would like to know.
Here’s a case that I find interesting that I have considered for Gambit but not implemented yet.
All Gambit input ports have a timeout setting which specifies when a port “read” that blocks will time-out. The time-out handler can be set with a call such as this:
(input-port-timeout-set! port 5 (lambda () (pretty-print 'time-out) #f)) (read port)
Here the time-out handler will be called if the (read port) doesn’t return within the next 5 seconds. The #f returned by the handler will cause the read to return an end-of-file (otherwise the operation will be retried).
Although the timeout feature is very useful it has the problem that there is just one timeout per port and the API mutates the port structure. It would be better to have one timeout per thread (and a different API to specify the timeout), so that different threads can specify a timeout that suits their needs. This is where a parameter object would be useful.
Each port would have a timeout parameter object attached to it and a thread would do something like:
(parameterize (((input-port-timeout port) (make-timeout-handler 5 (lambda () …)))) (read port))
The scope of this timeout would only apply to that port, in the current thread and in the scope of the parameterize.
I think that is a better API.
Marc