Jake It would be great if you give some examples when find your
notebook :) And link to the book about pure functional data structures
which you are talking about.
Also If some "haskell.org" maintainers are here I'd like to recommend
them to pay more attention to optimality/performance questions.
Because almost first question which is apeared in head of standart
C/C++ programmer is "Do I get same perfomance?" (even if he do not
need it).
Maybe some simple and cool PDF tutorial which describes why haskell
could be as fast as others will be great to have.
```
```
Richard A. O'Keefe:
> I am teaching myself haskell. The first impression is very good...
> Anyway I am trying to backport my algorithm written in C. The key to
> performance is to have ability to remove element from the end of a
> list in O(1).
You can't. Not in *any* programming language. That's because
lists are one of many possible implementations of the "sequence"
concept, and they are optimised to support some operations at
the expense of others. At the beginning level, you should think
of all Haskell data structures as immutable; fixed; frozen;
forever unchanged. You can't even remove an element from the
front of a Haskell list, at all. All you can do is to forget
about the original list and concentrate on its tail.
> But the original haskell functions last and init are O(n).
Haskell lists are singly linked lists. Even by going to
assembly code, you could not make these operations O(1)
without *using a different data structure*.
> My questions are:
> 1) Is last function is something like "black box" written in C++ which
> perform O(1)?
No.
> 2) Or will optimizer (llvm?) reduce init&last complexity to 1?
No.
> 3) Some people suggest to use sequences package, but still how do they
> implement O(1) init&last sequences equivalent in haskell?
Well, you could try reading Chris Okasaki's functional data
structures book.
There is a classic queue representation devised for Lisp
last century which represents
<a,b,c,d,e>
by ([a,b],[e,d,c])
so that you can push and pop at either end.
When the end you are working on runs out, you
reverse the other end, e.g.,
([],[e,d,c]) -> ([c,d,e],[]).
That can give you a queue with *amortised* constant time.
(There is a technical issue which I'll avoid for now.)
But let's start at the beginning.
You have an interesting problem, P.
You have an algorithm for it, A, written in C.
You want an algorithm for it, H, written in Haskell.
Your idea is to make small local syntactic changes
to A to turn in into H.
That's probably going to fail, because C just
loves to smash things, and Haskell hates to.
Maybe you should be using quite a different approach,
one that would be literally unthinkable in C.
After all, being able to do things that are unthinkable
in C is one of the reasons for learning Haskell.
Why not tell us what problem P is?
```
```
Tony Morris:
data SnocList a = SnocList ([a] -> [a])
Inserts to the front and end in O(1).
```
### I consider the follow dispositve on the subject.
```
Edward Kmett:
Note: all of the options for playing with lists and queues and fingertrees come with trade-offs.
Finger trees give you O(log n) appends and random access, O(1) cons/uncons/snoc/unsnoc etc. but _cost you_ infinite lists.
Realtime queues give you the O(1) uncons/snoc. There are catenable output restricted deques that can preserve those and can upgrade you to O(1) append, but we've lost unsnoc and random access along the way.
Skew binary random access lists give you O(log n) drop and random access and O(1) cons/uncons, but lose the infinite lists, etc.
Tarjan and Mihaescu's deque may get you back worst-case bounds on more of the, but we still lose O(log n) random access and infinite lists.
Difference lists give you an O(1) append, but alternating between inspection and construction can hit your asymptotics.
Lists are used by default because they cleanly extend to the infinite cases, anything more clever necessarily loses some of that power.
Chris Allen
10 years ago