[erlang-questions] Proposal: add lists:intersperse/2 and lists:intercalate/2

Michael Truog <>
Thu Mar 3 02:25:20 CET 2016

On 03/02/2016 10:28 AM, Joe Armstrong wrote:
> On Wed, Mar 2, 2016 at 3:47 PM, Jesper Louis Andersen
> <> wrote:
>> Hi Erlangers,
>> I'd really like to add two functions to the lists module from Haskell:
>> intersperse(List, Seperator) produces a list where each element is separated
>> by separator, i.e.
>> X = [1,2,3]
>> [1, x, 2, x, 3] = lists:intersperse(X, x),
>> and it's cousin, intercalate(ListOfLists, Separator) is
>> append(intersperse(ListOfLists, Seperator)), i.e,
>> Y = ["a", "b", "c"]
>> "a, b, c" = lists:intercalate(Y, ", "),
>> The implementations are straightforward and easy to write tests for, even
>> property based tests if needed.
>> The rationale for this proposal is that I find myself implementing this
>> function again and again in every project I write, and it is highly generic.
>> It belongs in a typical list module. OCaml libraries add it. Haskell's
>> Data.List has it. I believe Erlang, being a practical language, should have
>> it as well.
> This is a splendid function - I have one myself called interleave, the only
> problem is that if somebody uses this and puts their code in a library on github
> and somebody fetches this code and runs it with an *old* version of erlang
> then they will get a error and probably blame your code.
> This is why I have a single library called elib2_misc.erl where I put *all* the
> stuff that should be somewhere else - then I ship this with my code.
> The whole story of dependency analysis seems to be be in a very sad state.
> I use the 'keep your fingers crossed and hope it will work' method.
> Years ago I wanted to add a -needs(Vsn) annotation to module
> For example:
>       -needs(erl18).
> Means would mean you need version 18 of erlang.
> That way if you added a needs annotation to the code that used the updated lists
> then an earlier version of Erlang could give a meaningfull diagnostic
> and not just
> crash when the encountering a function 'from the future'.
> Actually I had another problem today - a program I wrote in 2003 did not work
> with the latest and greatest Erlang - not because the language had changed
> but because the library functions had been renamed and moved around.

combined with
https://github.com/erlang/eep/blob/master/eeps/eep-0044.md#the--error-directive should
do what you want, though it is more verbose and flexible.

> I guess a lint program would be useful here. It should be fairly
> doable to download
> all old erlangs and simple make lists of all the function names in all modules
> and do a bit of consistency checking.

Dialyzer seems like the Erlang lint program.  If the Erlang install automatically generated a
plt file for it, it might be a bit easier to use it as part of normal compilation.

The alternative
might be to use http://erlang.org/doc/man/xref.html as a command line tool, if the checking
needs to only consider functions and not types.  I am not aware of a standalone (escript)
to run xref, but that may be useful for normal Erlang development (aside from rebar or
other build tool usage).

More information about the erlang-questions mailing list