[r6rs-discuss] [Formal] FIND delivers an ambiguous value

[Shiro Kawai]

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