On Wed, Aug 31, 2005 at 09:36:20AM +0100, Tony Garnock-Jones 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...)

True, but the implementation is already there for those who want
something rigorous. :)

> To be even pickier, I suppose, one might insist upon
>   (define hash-table-ref/default
>     (let ((hash-table-ref hash-table-ref))
>       (lambda (...) ...)))

Ouch.  Actually, this is the kind of sublety that I want to avoid by
_not_ using code in the definition.  Code overspecifies many things;
written English allows us to be elliptical.  (Of course, sometimes
that's a con, too...)

> > 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)

Interesting.  I would have thought cut would work, itself being a macro.
(You can write higher-order macros no prob; it's just that functions
can't use macros.)  So I went forth and tried it out.  Seems that the
SRFI (cut) implementation explicitly tries to disallow this by expanding
into ...((begin hash-table-ref)...)... instead of simply
...(hash-table-ref...)...

I know that macros are shunned because of reasons like this.  IMO, it's
a pity that macros don't enjoy wider usage (and consequently, support)
in the Scheme community.

> 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.

It's just that viewed differently, (hash-table-ref) can be seen as a
kind of control structure, similar to (and) or (if).

> (Aside: I was just considering whether using promises instead of lambdas
> would be a good idea here. Does *anyone* use delay/force? Ever?)

Using promises could be a good idea.  delay and force are quite a dark
corner in Scheme, though; I read somewhere they might be purged in a
forthcoming RnRS.  While they _are_ used for streams and such, their
usefulness does not seem great enough to be supported by the base
language.

Actually, to be really useful, promises should be implicitly forced.
This would make them a "real" abstraction vehicle.  But this has wide
ramifications in the language...

Panu

--
personal contact: xxxxxx@iki.fi, +35841 5323835, +3589 85619369
work contact: xxxxxx@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/