Added insertAt, rewrote splitAt to use new helper

[mrbackend]

Added insertAt. It is stack safe and about twice as fast as (take n xs) ++ (value :: drop n xs). As it happened, one of the helpers turned out to suit splitAtvery well, so I rewrote that one to use the new helper. Fuzz tests for insertAt included - splitAtalready had tests.

Running elm-format 0.5.2-alpha introduced a couple of other modifications.

[Chadtech]

Awesome. It's some what surprising that we dont have insertAt already, considering we have removeAt and updateAt.

I would like to merge this, but I have a few considerations:

0 The first of which, is that insertAt is kind of a code smell that one shouldnt be using a List in the first place. Im not saying we shouldnt include it in list-extra, but we should put a warning or something in the docs. Also, do you have in mind some use case where you would need insertAt and where it makes sense to use a list? We talked about this a bit in the slack, and @eeue56 pointed out one such use case: to avoid run time errors associated with Array (not sure what he means, but I trust him that such run time errors exist).

1 Could you put in a code example in your docs? Something like what is in @knuton 's insertAt PR.

[n1k0]

Dunno why this PR has never landed but fwiw and for those like me who're looking after insertAt, most often it's actually as simple as using splitAt:

insertAt : Int -> a -> List a -> List a
insertAt index item items =
    let
        (start, end) = splitAt index items 
    in
        start ++ [ item ] ++ end

[Erudition]

some use case where you would need insertAt and where it makes sense to use a list

Yes. I have a List because according to canonical Elm theory, List vs. Array should be decided based on which use cases you use most often - e.g. If you find yourself scanning and inserting and indexing a lot, it's more efficient to use an Array, and if you more often find yourself taking the head of a list and just appending things to the front (like with ::) or doing tail-call-optimized stuff, then List is what you want.

Based on that advice, List is what I want, because with my use case, I'm recording moments in time and constantly adding them to the head of the list, and almost always access just the head. But just because that's what I do most often with my data structure, doesn't mean it's the only operations I may want to do with it.

I'm building a function that will patch up some holes in the list (timeline) by backfilling a few moments (entries) that got synced from elsewhere. Thus I need to insertAt the right spot. Given this list will only ever grow larger, and given the principle of choosing the right data structure, I don't think it makes sense to convert to Array and back whenever I do this. A List.insertAt function makes the most sense in this case.