Lambda The Ultimate: use failure-thunk instead of default value? Tony Garnock-Jones (07 Jul 2005 09:58 UTC)
|
Re: Lambda The Ultimate: use failure-thunk instead of default value?
Panu Kalliokoski
(07 Jul 2005 12:25 UTC)
|
Re: Lambda The Ultimate: use failure-thunk instead of default value?
Tony Garnock-Jones
(07 Jul 2005 13:14 UTC)
|
Re: Lambda The Ultimate: use failure-thunk instead of default value?
Panu A Kalliokoski
(08 Jul 2005 14:19 UTC)
|
Re: Lambda The Ultimate: use failure-thunk instead of default value?
Thien-Thi Nguyen
(08 Jul 2005 06:21 UTC)
|
Lambda The Ultimate: use failure-thunk instead of default value? Tony Garnock-Jones 07 Jul 2005 09:58 UTC
Some schemes (eg. mzscheme) have a hash-table-get with signature (hash-table-get hash-table key-v [failure-thunk]) using a failure-thunk instead of a default value. Most of the time I use hash tables, I find this to be more elegant, and whenever I'm using a scheme that uses default values instead of a failure-thunk, I find myself eventually overriding the hash table accessor with my own custom version because failure-thunks are so much more convenient. They feel a bit like alternate continuations. For instance, I prefer to write: (hash-table-get valmap id (lambda () (error "Object does not contain slot" (desc-id-and-slot id slotname)))) rather than: (let* ((*failure* "failure") (result (hash-table-get valmap id *failure*))) (if (eq? result *failure*) (error "Object does not contain slot" (desc-id-and-slot id slotname)) result)) The concision of the common default-value case can be regained with a procedure "always": (define (always something) (lambda () something)) (hash-table-get *forward-slots* id (always #f)) Regards, Tony