[erlang-questions] lists:keyfind as an alternative to lists:keysearch

[Hynek Vychodil]

On Wed, Jan 21, 2009 at 10:56 AM, Richard Carlsson <richardc@REDACTED>wrote:

> Bjorn Gustavsson wrote:
> > On Tue, Jan 20, 2009 at 4:15 PM, James Hague <james.hague@REDACTED>
> wrote:
> >> I would like to propose the addition of lists:keyfind/3, which is
> >> identical in structure to lists:keysearch/3, except that it returns
> >> either 'false' or the found tuple, with no additional wrapping of the
> >> result.  This can be trivially added to the lists module:
> >>
> >>   keyfind(K, N, L) ->
> >>      case keysearch(K, N, L) of
> >>         {_, Tuple} -> Tuple;
> >>         X -> X
> >>      end.
> >>
> >
> > Good idea.
> >
> > Unless someone has any good reasons agains this suggestion, we will
> probably
> > implement it in R13. (lists:keyfind/3 will be a BIF, and
> > lists:keysearch/3 implemented
> > in Erlang.)
>
> Only that I always wince at the mixing of 'false' with {...}. Since this
> is a new function, I'd prefer 'error' (to pick another atom that is
> frequently used in Erlang libraries).


I don't understand why 'error' is better than 'false'. 'false' is more
broadly used than 'error' because it is all conditions result. Anyway when I
ask someone to find something I found to get answer 'found' x 'not found'
more expected than 'found' x 'error'. 'false' sounds for me as better answer
to ask for `find` as 'true' I have found x 'false' I haven't found. Not
found is not error, it is false result.

>
>
>    /Richard
>
>
> (Singing: "Eric the half-a-bool...")
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill your
boss.  Be a data hero!
Try Good Data now for free: www.gooddata.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090121/3ed225c7/attachment.htm>