From: Andre van Tonder <andre_at_het.brown.edu>
Subject: Re: [r6rs-discuss] [Formal] FIND delivers an ambiguous value
Date: Wed, 1 Nov 2006 14:48:22 -0500 (EST)
> But in your use case, don't you normally have to check the
> return value anyway? If so, there very little
> difference between writing:
>
> (let ((x (memp p list))) ; equivalent to suggested modification
> (if x
> (do-something (car x))
> (do-something-else)))
Suppose you use the found element many times in the let body.
Replacing all occurrences of x to (car x) makes code cumbersome
to read.
(I frequently use 'find' with and-let*, so the pattern
may be just one more line to extract the element:
(and-let* ((x (memp p list))
(elt (car x)))
;; use 'elt' many times
)
But still, it's so frequent that it would deserve an abstraction.)
> Sometimes memp can be more concise. The following is a very common use case:
>
> (cond ((memp p list) => car) ; equivalent to suggested modification
> (else 'error))
Suppose you have a function PROC that expects an element in the
list. The difference becomes:
(cond ((memp p list) => (lambda (x) (proc (car x))))
(else 'error))
(cond ((find p list) => proc)
(else 'error))
Variation of this case: when PROC accepts "either an element
of LIST or #f", the difference becomes:
(proc (cond ((memp p list) => car) (else #f)))
(proc (find p list))
This pattern especially appears for optional arguments with
#f as the default value.
I scanned through my code to see how I use 'find', and these are
the patterns I use mostly.
However, if we want to cut down the amount of the standard, I
don't mind 'find' to be dropped as far as we have a strong
separate library like srfi-1.
--shiro
Received on Wed Nov 01 2006 - 15:47:34 UTC