note
Dominus
Says [gjb]:
<blockquote><i>
As an aside, to illustrate the elegance of functional languages, consider the quicksort in Haskell.
<code>
qsort [] = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_gr_x
where
elts_lt_x = [y | y <- xs, y < x]
elts_gr_x = [y | y <- xs, y > x]
</code>
</i></blockquote>
There's a very cool thing about this that you didn't mention.
Sometimes in newsgroups or on this web site you see beginners do this:
<code>
($minimum) = sort {$a <=> $b} @items;
</code>
when they want to find the minimum value in an array of numbers.
And then other folks usually tell them that that is a bad move, because
the <tt>sort</tt> takes <i>O</i>(<i>n</i> log <i>n</i>) time,
but
to scan the array looking for the minimum only takes
<i>O</i>(<i>n</i>) time. This means that if you
double the length of the array,
the scan will take exactly twice as much time, but the <tt>sort</tt>
will take more than twice as much time, and so no matter
how fast your sorting is, for sufficiently large lists,
the scan will be faster. Unfortunately, the array scan requires more
code and isn't as transparently obvious. <p>
The astonishing thing about the Haskell implementation is that you can write
the analogous code:
<code>
minimum = head(qsort array);
</code>
and it <i>will</i> run in <i>O</i>(<i>n</i>) time.
Sorting the whole list would require <i>O</i>(<i>n</i> log <i>n</i>) time,
but Haskell figures out that it doesn't need
to sort the entire list, and it manages to run the <tt>qsort</tt>
function partially, just enough to sort the first
element to the front. I find it incredible that
this optimization just falls out naturally from Haskell's
way of doing things.<p>
This isn't a result of the fact that Haskell's a
functional language, but rather that it's a <i>lazy</i>
language. But it's difficult to imagine a usefully lazy language that
wasn't also functional. The quest for useful laziness like
this is one of the primary motivators for studying functional
languages in the first place. A simpler example looks like this:
<code>
sub zero {
return 0;
}
$x = zero(SOME_VERY_LONG_COMPLICATED_EXPRESSION);
</code>
Here Perl, in spite of claiming the virtue of laziness,
computes the value of the long complicated expression,
but
then throws it away and assigns zero to <tt>$x</tt>.
The analogous code in Haskell never computes the value
of the long complicated expression at all.<p>
(Translation of the <tt>qsort</tt>
for non-Haskell users: <tt>&#91;]</tt> is the empty list;
<tt>&#91;x]</tt> is a list that has just x and nothing else;
<tt>++</tt> is the operator that appends two lists head-to-tail,
and <tt>x:xs</tt> is the list you get by taking the list <tt>xs</tt>
and appending <tt>x</tt> to the front. (So <tt>&#91;x]</tt> and <tt>x:&#91;]</tt>
mean exactly the same thing.) [gjb] left a little bit of code off the
end of the function, which I added back. <tt>&#91;y | y <- xs, y > x]</tt>
is something like Perl's <tt>map</tt> plus <tt>grep</tt>.
It makes a list of all the <tt>y</tt> values from the list <tt>xs</tt>,
subject to the constraint that <tt>y > x</tt> must be true.
So <tt>&#91;BLAH(y) | y <- xs, COND(y)]</tt> is very much like
perl's <tt>map BLAH($_), grep COND($_), xs</tt> construction.
Now you know Haskell. <tt>:)</tt> )
<p>
--<br><font size="-2">
<a href="mailto:mjd-www-perlmonks+@plover.com">Mark Dominus</a><br>
<a href="http://perl.plover.com">Perl Paraphernalia</a><br></font>
205797
205962