I will just comment some of the many threads going in this discussion. Without making any concrete suggestions I want to say that I would have nothing against adding a find_index, elem_index and unfoldl to lists.<br><br><div class="gmail_quote">
2008/11/27 Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
</div>
This raises the question of what value should be returned<br>
when no element of the list satisfies the search criterion.<br>
0 is a popular decision, going back to BASIC, but one that<br>
makes very little sense.  The version that actually makes<br>
the most sense is length(Xs)+1, so that<br>
<br>
        elem_index(E, Xs) -> find_index(fun (X) -> X =:= E end).<br>
        find_index(P, Xs) -> 1 + length(drop_while(P, Xs)).<br>
<br>
because that makes reasoning about programs that use it<br>
noticeably freer of special cases.<br>
<br>
Returning something that isn't a number (my choice here would<br>
have been 'absent') has the advantage that failing to find<br>
something would be unlikely to go un-noticed.  It's awkward<br>
with a type checker though.<br>
<br>
The only advantages of returning 0 seem to be "consistency<br>
with old fashioned BASIC" and "simplicity for the type checker".<br>
It makes reasoning about a program more awkward than it need<br>
be, and it makes it far too easy to fail to notice that<br>
something wasn't found.<br>
<br>
The Haskell versions *force* you to check whether something<br>
was found or not; I suppose the nearest Erlang analogue<br>
would be to return {present,Index} for something found and<br>
'absent' for something not found.<br>
<br>
Summary: I recommend adopting/adapting the Haskell names,<br>
and there's a choice between<br>
Index|absent, Index|0, Index|length+1, {present,Index}|absent<br>
for the result.</blockquote><div><br>I would probably opt for something which resembles Haskell's Maybe Type and use:<br><br>maybe(Type) = {yes,Type} | no.<br><br>if I have understood Haskell's Maybe corectly, and Erlang type declarations. This is a return format I would like to use often, and we should have used it often too.<br>
<br>I would not directly follow the conventions in string, they are very much taken from the libc equivalents and make much more sense in C than they do in Erlang.<br><br></div>Re names of functions, lists is probably not an example of good naming conventions. Why there are no separated_names I can't remember, most likely it just happened and the local convention was just continued. The names for many of the higher order functions came from Haskell or similar and there they did not use separated_names. It is not a convention that need be followed.<br>
<br>Robert<br><br></div>