[erlang-questions] Additions to lists module

[Richard O'Keefe]

On 27 Nov 2008, at 7:02 pm, Roessner, Silvester wrote:

> On  27. November 2008 02:32 Richard O'Keefe wrote
>
>> This raises the question of what value should be returned when no  
>> element of the list satisfies the search criterion.
>
> I would prefer a list. It is empty if there is no matching element  
> or has exactly one member, the index.

I didn't mention the other two members in the group of related
Haskell functions:

     elemIndices :: Eq x =>   x -> [x] -> [Int]
     findIndices :: (x -> Bool) -> [x] -> [Int]

So yes, lists make sense as a "poor man's Maybe".
>
>
> I also would join all of the mentioned funtions in only one, like
>
>> %% @spec (List::list(), Ele) -> [integer()]
>> %% @doc Returns the position of `Ele' in the `List'. [] is returned
>> %%      when `Ele' is not found.
>> %% @end
>
>     find_index(List, Element, Option) -> [Index]
>     find_index(List, Element) = [Index]
>
> 	Option = only_first | only_last | [every]

The distinction between ELEM_index (seek an element)
and FIND_index (seek anything satisfying a predicate) is important,
so it would be a great pity to use the wrong name here.

There doesn't seem to be any point in putting square brackets
around 'every', and the option names might as well be single
syllables:
	Option = first | last | all

So we'd have
	find_index(Predicate, List, Wanted) -> [Index]
	find_index(Predicate, List)         -> [Index]
	elem_index(Element,   List, Wanted) -> [Index]
	elem_index(Element,   List)         -> [Index]

The argument order would then be compatible both with the
Haskell versions and, more importantly, with member/2:

	member(Element, List) -> elem_index(Element, List) =/= [].	

I like the fact that you can briefly get the index if you are
certain that there is one using hd(elem_index(E, L)), with a
runtime check happening in case you were wrong.

As a general design principle, I'm not that thrilled with
function arguments that say which of several functions you
*really* meant to call.  They have their place in languages
with very weak modularisation, but in a language like
Erlang, it just feels wrong.  I always find myself wondering
what other option values there might have been and then
being annoyed that they don't exist.  When implementing such
a thing, I usually find myself writing all the special case
functions anyway, and wondering why they weren't just
exported in the first place.

One reason is that the option might be computed at run time,
but is that really a live issue here?

I wonder if we might find some sort of intermediate place
between "you are left to cope by yourself" and "here is
everything you might possibly need in the library".  Just a
plain text file with a whole lot of example functions that
people have noted as being useful, so that you don't have to
invent them, but that are not part of the supported library,
so the Erlang/OTP team don't have to document and maintain them?

is an Erlang cook
block
functions you r