<div dir="ltr">lists:member/2 matches (using =:=) entire elements to determine whether or not they are present in the list, whereas the proposed lists:find/2,3 allows the caller to pass a fun to test for element presence. The fun allows the caller to ignore fields of an element that's a tuple, record etc. for purposes of determining whether something is or is not present in the list. Therefore lists:member/2 can't do what the proposed lists:find/2,3 can do.<div>
<br></div><div>--steve</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 9:08 AM, Serge Aleynikov <span dir="ltr"><<a href="mailto:serge@aleynikov.org" target="_blank">serge@aleynikov.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Since finding an element in the list is already doable via lists:member/2, it seems to me that there's very little benefit in that find/2 function. Whereas a more valuable addition would be to find an index of the element in the given list. An example of a common use case for that would be to locate a field's position in a mnesia table by name (e.g. index_of):</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">update_table(Table, FieldName, Value) -></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
Attrs = mnesia:table_info(Table, attributes),</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> {ok, Pos} = index_of(FieldName, Attrs),</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
R = mnesia:dirty_read(Table, Key),</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> R1 = setelement(Pos, R, NewValue),</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
ok = mnesia:dirty_write(Table, R1).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">index_of(Value, List) -></div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> index_of(Value, List, 1).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">index_of(V, [V|T], N) -></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
{ok, N};</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">index_of(V, [_|T], N) -></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> index_of(V, T, N+1);</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">index_of(_, [], _) -></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> false.</div></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 5:48 AM, Thomas Järvstrand <span dir="ltr"><<a href="mailto:tjarvstrand@gmail.com" target="_blank">tjarvstrand@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>A more generic version would be to return the first result of applying the fun to an element that does not return false. That way you can choose whether to return the actual element, the result of the computation you just or even something completely different. The user is also free to wrap the result in case he/she is worried that the return value might be `false`.<br>
<br>Example implementation:<br><b><span style="font-family:courier new,monospace">find(_MatchF, []) -><br></span></b></div><b><span style="font-family:courier new,monospace"> false;<br></span></b><div><b><span style="font-family:courier new,monospace">find(MatchF, [X|Xs]) -><br>
case MatchF(X) of<br> false -> find(MatchF, Xs);<br> Val -> Val<br> end.</span></b><br><br></div><div>Thomas<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/22 Anthony Ramine <span dir="ltr"><<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forwarding to list.<br>
<span><font color="#888888"><br>
--<br>
Anthony Ramine<br>
<br>
Le 22 oct. 2013 à 11:56, Anthony Ramine <<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>> a écrit :<br>
<br>
> Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not F(X) end, L).<br>
><br>
> Of course, the function would be written less naively to avoid constructing a new fun.<br>
><br>
> --<br>
> Anthony Ramine<br>
><br>
> Le 14 oct. 2013 à 15:52, Sean Cribbs <<a href="mailto:sean@basho.com" target="_blank">sean@basho.com</a>> a écrit :<br>
><br>
>> #1: Would tagging the return value address like Masklinn mentions address your concern? {ok, Term} | error (instead of a default value)?<br>
>><br>
>> #2: Also, I considered dropwhile but it involves introducing another fun, whereas the version I wrote is direct.<br>
</font></span><div><div>>><br>
>><br>
>> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine <<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>> wrote:<br>
>> Hello Sean,<br>
>><br>
>> I don't like this patch.<br>
>><br>
>> 1/ You can't know whether an element was found or not if the list elements are arbitrary terms.<br>
>> 2/ I don't see why you would say people hack either foreach/2 or foldl/3 to do that when they should just use dropwhile/2.<br>
>><br>
>> A naive implementation of find/2 using dropwhile/2:<br>
>><br>
>> find(F, L) -><br>
>> case dropwhile(fun (E) -> not F(E) end, L) of<br>
>> [] -> undefined;<br>
>> [E|_] -> E<br>
>> end.<br>
>><br>
>> Regards,<br>
>><br>
>> --<br>
>> Anthony Ramine<br>
>><br>
>> Le 14 oct. 2013 à 02:44, Sean Cribbs <<a href="mailto:sean@basho.com" target="_blank">sean@basho.com</a>> a écrit :<br>
>><br>
>>> `lists:find/2,3` returns the first element of the passed list for which the predicate fun returns `true`. If no elements result in the predicate being true, `undefined` (/2) or the given default value (/3) is returned.<br>
>>><br>
>>> ## Why this new feature?<br>
>>><br>
>>> A common task is to select the first element from a list that matches a condition, but there is no existing lists function or language feature that avoids traversing the entire list, while still returning a "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive search for the matching item without resorting to exceptions (used to abort `foreach/2` or `foldl/3`) and always returns either the first matching item, or an otherwise safe value.<br>
>>><br>
>>> ## Risks / uncertain artifacts<br>
>>><br>
>>> It is unclear the desired order of arguments for the 3-arity version. I have made the default value the final argument which is consistent with `application:get_env/3` and `proplists:get_value/3`, but most functions in lists place the `List` argument last.<br>
>>><br>
>>> ## How did you solve it?<br>
>>><br>
>>> Following the patterns of other functions in the lists module, `lists:find/3` tests the predicate function against the head of the list, returning the head if the predicate passes, or recursing over the tail if it does not.<br>
>>><br>
>>> <a href="https://github.com/erlang/otp/pull/102" target="_blank">https://github.com/erlang/otp/pull/102</a><br>
>>><br>
>>> --<br>
>>> Sean Cribbs <<a href="mailto:sean@basho.com" target="_blank">sean@basho.com</a>><br>
>>> Software Engineer<br>
>>> Basho Technologies, Inc.<br>
>>> <a href="http://basho.com/" target="_blank">http://basho.com/</a><br>
>>> _______________________________________________<br>
>>> erlang-patches mailing list<br>
>>> <a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
>>> <a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Sean Cribbs <<a href="mailto:sean@basho.com" target="_blank">sean@basho.com</a>><br>
>> Software Engineer<br>
>> Basho Technologies, Inc.<br>
>> <a href="http://basho.com/" target="_blank">http://basho.com/</a><br>
><br>
<br>
_______________________________________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
<br></blockquote></div><br></div>