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

Jesse Gumm gumm@REDACTED
Wed Mar 2 21:01:22 CET 2016


I'd like to go ahead and throw in a big fat "same".  I've also
reimplemented the wheel in Nitrogen with a `join` function that
interleaves a list of things with some other things. So cast my vote
for a lists:join. `join` I would argue is much more accessible, as 1)
it's quite common in other languages, 2) stays remains consistent with
string:join and filename:join, and 3) brevity is awesome.

-Jesse

On Wed, Mar 2, 2016 at 12:28 PM, Joe Armstrong <erlang@REDACTED> wrote:
> On Wed, Mar 2, 2016 at 3:47 PM, Jesper Louis Andersen
> <jesper.louis.andersen@REDACTED> 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.
>
> 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.
>
> Cheers
>
> /Joe
>
>
>
>
>> Thoughts?
>>
>> --
>> J.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions



-- 
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm



More information about the erlang-questions mailing list