This page is part of the web mail archives of SRFI 69 from before July 7th, 2015. The new archives for SRFI 69 contain all messages, not just those from before July 7th, 2015.
Panu Kalliokoski wrote: > How about "behaves as if it evaluates to"? I like including the code verbatim, rather than relying on the English prose, since the code has a well-defined semantics. (I'm reminded of one of the original goals for and uses of Scheme: to communicate algorithms unambiguously in academic papers...) To be even pickier, I suppose, one might insist upon (define hash-table-ref/default (let ((hash-table-ref hash-table-ref)) (lambda (...) ...))) :-) > By the way, I got no comments to the suggestion that there would be > [...] a _macro_ hash-table-ref [...] I don't think it's a good idea. Not only does it make it non-obvious whether the "default" form is evaluated or not, it makes it impossible to use hash-table-ref itself as a higher-order function, for instance with srfi-26's (cut), or with (curry): (map (cut hash-table-ref t <> (lambda () #f)) my-keys) (define my-lookup (curry hash-table-ref my-table)) Of course, you could use hash-table-ref*, or whatever the non-macro version of the procedure is, but to me the addition of a macro seems excessive for a very small win. For most cases, I imagine using hash-table-ref/default would be good enough. In cases where the default value is expensive to compute - exactly those cases you really want the thunk to delay the computation - I like being reassured that the computation is definitely being delayed by the physical presence of a (lambda () ...) at the calling site. (Aside: I was just considering whether using promises instead of lambdas would be a good idea here. Does *anyone* use delay/force? Ever?) Tony