The peristent red black tree in last post works ok, but the rotate functions and
color flip is not efficient for purely functional data sturctures.
In 1999, Okasaki introduced a new way to balance the insertion, and the function
only takes care of four unbalanced cases.
"Red-Black Trees in a Functional Setting",
Journal of Functional Programming, 9(4),
(time(loopforifrom1to1000000do(rb-inserti)));; The original algorithm using rotate-s and rotate-d19.796secondsofrealtime18.570645secondsoftotalruntime(17.423563user,1.147082system)[Runtimesconsistof3.043secondsGCtime,and15.528secondsnon-GCtime.]93.81%CPU47,299,915,377processorcycles6,522,724,144bytesconsed;; The Okasaki's algorithm13.005secondsofrealtime12.193227secondsoftotalruntime(11.213534user,0.979693system)[Runtimesconsistof2.513secondsGCtime,and9.681secondsnon-GCtime.]93.76%CPU31,073,022,018processorcycles4,278,336,384bytesconsed
Lisp is designed for bottom-up programming. You first draft what you want to do,
then you can start to write some functions and macros to simplify it. When there
are more and more utilities you written, you can use it to experiment more
complicated algorithms, in a more elegant and self expressive style.
In purely functional structure, Haskell code seems to be more elegant because
it has built in pattern matching, while we have to write one for Lisp. But Lisp
provides things more than functional programming, it can also be written in
procedure style, object-oriented style, or any other DSL that is best suitable
for your objective.
The macro system in lisp can also improve your thinking of designing a program.
Because you can always abstract your program structure as you writing it. In
other language you are trained to think top-down, while in lisp you are
encouraged to think back and forth. This process can shorten required time to
get enough experiences of programming. You don’t need a lot experiences to build
a complex algorithm in a bottom-up design process. It’s just come up naturally.