Making it the default behavior would require it to be a macro instead of an ordinary function, so you’d lose the ability to pass it around as a function. Given that implementing a short circuit macro on top of hash-ref! is as simple as (define-syntax-rule (hash-ref!! table key expr) (hash-ref! table key (thunk expr))), whoever made the decision probably figured that the loss of the ability to use it as a first-class function wasn’t worth making a one-line macro default behavior.
On Fri, Nov 7, 2014 at 1:08 PM, Matthew Butterick <m...@mbtype.com> wrote: > Since `hash-ref!` includes `or`-like functionality, is there a reason it's > not implemented with short-circuit logic similar to `or`? > > In other words, the function `hash-ref!` is invoked thus: > > (hash-ref! hashtable key new-value-if-needed) > > What I notice is that if you put an expression in the new-value position, > like so: > > (hash-ref! hashtable key (expression-that-produces-value)) > > Then this expression will always be evaluated before the function is > called. > > But this seems wasteful, since if 'key' exists in 'hashtable', the > expression won't be needed. > > `hash-ref!` will also take a thunk, so you can manually delay evaluation > of the value expression by wrapping it in λ: > > (hash-ref! hashtable key (λ () (expression-that-produces-value))) > > But I'm curious why delayed evaluation isn't the default behavior. > ____________________ > Racket Users list: > http://lists.racket-lang.org/users >
____________________ Racket Users list: http://lists.racket-lang.org/users
