Data.Sequence.splitAt semantics are unfortunate

[haskell]

Data.Sequence.splitAt semantics are unfortunate

[tibbe]

Being lazy in the base case, like the Prelude's take is usually not very useful and hurts performance because other arguments can no longer be unboxed (because they might not be used). In other places in containers (e.g. Data.IntMap.lookup) I believe being lazy in the base case costs as much as 10% performance.

I even wrote about it: http://johantibell.com/files/haskell-performance-patterns.html#(11) (and also elsewhere).

[treeowl]

@tibbe In the page you linked to, laziness in the base case prevents the Int argument from being unboxed, which is obviously bad. In this case, laziness in the i<=0 case does not do this, so it's not clear to me whether it's bad or not. That said, I think we can probably both agree that the current implementation is the worst of both worlds. I don't mind following GHC's semantics (as described above), and I also don't mind switching to completely strict semantics for this.

[treeowl]

Fixed by aaf5408