4 ms·

Haskell has list fusion so efficient list code never actually constructs a list that lives on the heap to be GC'd to start with. So, with that proviso, the ans

Haskell has list fusion so efficient list code never actually constructs a list that lives on the heap to be GC'd to start with. So, with that proviso, the answer to your question is yes and that as a result sometimes list code can be faster than vectors.

jblow 10y ago
[citation needed, in the form of actual benchmarks] The thing is that list fusion and whatnot is all just there to get around the handicap that was placed there in the first place by the language paradigm. So you start by insisting on shooting yourself in the foot, then put lots of armor on your boot so the bullet hopefully bounces off. I assume by "vectors" you mean arrays ... there is no case in which this can be faster than arrays, because in the limit, if the list fusion system works perfectly, it is just making an array. A thing can't be faster than itself.
- coolsunglasses 10y ago
  If you need something predictable, you'll usually use a vector in Haskell. Nothing obligates you to use a list. I regard it as more of a pleasant surprise and something that surprises/confuses people when they benchmark `String` (which is `[Char]` under the hood) against `Text` (which is an `Array` under the hood: http://hackage.haskell.org/package/text-1.2.2.1/docs/src/Data-Text-Internal.html#Text http://hackage.haskell.org/package/text-1.2.2.1/docs/src/Dat... ) I've had `String` come out faster than `Text` in benchmarks plenty of times, including for a colleague when we were writing up this post https://lorepub.com/post/2016-12-17-Haskell-Pitfalls https://lorepub.com/post/2016-12-17-Haskell-Pitfalls What I'm not going to do is perform free labor for a man with a bad attitude who is 100x wealthier than I am. I'm not saying you should design a performance oriented language around short-cut fusion, but the "cost" of using Haskell is generally not what people think it is. The span of applicability for Haskell, IME, ranges from Java/Golang to Ruby. It's no replacement for C++, but it does come close in some applications that aren't hard/soft real-time.

jblow 10y ago

[citation needed, in the form of actual benchmarks] The thing is that list fusion and whatnot is all just there to get around the handicap that was placed there in the first place by the language paradigm. So you start by insisting on shooting yourself in the foot, then put lots of armor on your boot so the bullet hopefully bounces off. I assume by "vectors" you mean arrays ... there is no case in which this can be faster than arrays, because in the limit, if the list fusion system works perfectly, it is just making an array. A thing can't be faster than itself.

coolsunglasses 10y ago
If you need something predictable, you'll usually use a vector in Haskell. Nothing obligates you to use a list. I regard it as more of a pleasant surprise and something that surprises/confuses people when they benchmark `String` (which is `[Char]` under the hood) against `Text` (which is an `Array` under the hood: http://hackage.haskell.org/package/text-1.2.2.1/docs/src/Data-Text-Internal.html#Text http://hackage.haskell.org/package/text-1.2.2.1/docs/src/Dat... ) I've had `String` come out faster than `Text` in benchmarks plenty of times, including for a colleague when we were writing up this post https://lorepub.com/post/2016-12-17-Haskell-Pitfalls https://lorepub.com/post/2016-12-17-Haskell-Pitfalls What I'm not going to do is perform free labor for a man with a bad attitude who is 100x wealthier than I am. I'm not saying you should design a performance oriented language around short-cut fusion, but the "cost" of using Haskell is generally not what people think it is. The span of applicability for Haskell, IME, ranges from Java/Golang to Ruby. It's no replacement for C++, but it does come close in some applications that aren't hard/soft real-time.