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

[Hynek Vychodil]

On Wed, Jan 21, 2009 at 12:12 PM, Bengt Kleberg
<bengt.kleberg@REDACTED>wrote:

> Greetings,
>
> Rickard has my support. I, too, find mixing boolean and none boolean
> return values surprising.
>
> Perhaps {} (empty tuple) is an appropriate return value if nothing is
> found?
>

Erlang is not C thus we don't must return same type as for example -1 in C
used to error result. Erlang have atoms (and works as well as -1 in C) thus
just use it.
Empty list [] sounds good for function which returns list of results but
empty tuple {} is not empty variant for tuple. Tuple is not collection it is
just tuple. Tuple with different sizes are different types. List with
different amount of members are same types. There is big semantic shift.

>
>
> bengt
>
> On Wed, 2009-01-21 at 11:50 +0100, Mikael Pettersson wrote:
> > Richard Carlsson writes:
> >  > 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).
> >
> > Except that it's not actually an error to ask "search list L
> > for a tuple T with value K in element N and return T, or tell
> > me if none could be found". So I'd argue that 'false' is much
> > more appropriate than 'error'.
> >
> > At least, _I_ don't want that to be an error, since that would
> > require silly coding like:
> > 1. ask if the element is there, but don't return it (query, boolean)
> > 2. if it's there, get it (lookup, throws exn on failure not never here)
> > when what one often wants is:
> > 1. if the element is there, return it, otherwise return 'no'
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> 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/e0bdfa40/attachment.htm>