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