[erlang-questions] Additions to lists module

[Robert Virding]

 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.

2008/11/27 Richard O'Keefe <ok@REDACTED>

>
>  This raises the question of what value should be returned
> when no element of the list satisfies the search criterion.
> 0 is a popular decision, going back to BASIC, but one that
> makes very little sense.  The version that actually makes
> the most sense is length(Xs)+1, so that
>
>        elem_index(E, Xs) -> find_index(fun (X) -> X =:= E end).
>        find_index(P, Xs) -> 1 + length(drop_while(P, Xs)).
>
> because that makes reasoning about programs that use it
> noticeably freer of special cases.
>
> Returning something that isn't a number (my choice here would
> have been 'absent') has the advantage that failing to find
> something would be unlikely to go un-noticed.  It's awkward
> with a type checker though.
>
> The only advantages of returning 0 seem to be "consistency
> with old fashioned BASIC" and "simplicity for the type checker".
> It makes reasoning about a program more awkward than it need
> be, and it makes it far too easy to fail to notice that
> something wasn't found.
>
> The Haskell versions *force* you to check whether something
> was found or not; I suppose the nearest Erlang analogue
> would be to return {present,Index} for something found and
> 'absent' for something not found.
>
> Summary: I recommend adopting/adapting the Haskell names,
> and there's a choice between
> Index|absent, Index|0, Index|length+1, {present,Index}|absent
> for the result.


I would probably opt for something which resembles Haskell's Maybe Type and
use:

maybe(Type) = {yes,Type} | no.

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.

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.

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.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081127/a5842a3d/attachment.htm>