Thanks for reply and the workaround under "use strict". The solution works well, although it is a little different from my own consideration, which hopes that those variables need no declaration.
The demo code give such an algorithm - it looks like quicksort, but it's simpler and much slower. The function takes a list, taking its first element as a "pivot". Then the remaining list (tail of the list), namely "unsorted", is divided into two sub-lists: one contains elements which are no bigger than the pivot, and the other contains elements which are bigger than the pivot. The same process is applied to the two sub-lists unless the argument list is empty.
Quicksort is much faster, for it costs less time when dividing the original list. In addition, the strategy to choose a pivot is sometimes ingenious.
As for advantages of functional style over other paradigms, my opinion is that most of the time a piece of code which follows functional paradigm runs under a heavier burden, perhaps from its runtime mainly. However, there are reasons for following such discipline:
1. To think from a different perspective, which tells one to focus on functions and their composition, encourages one to write operators (i.e. functions that return functions) as glue between operations. Thus, some achievement in reusability could be somewhat reached.
2. More or less, such discipline encourages one to write smaller functions with clearer boundaries.
I myself usually consider functional paradigm able to be graceful. It's actually not always graceful, however.
In reply to Re^2: A "Fun"ctional Attempt
by withering
in thread A "Fun"ctional Attempt
by withering
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |