in reply to RFC: A Perlesque Introduction to Haskell, Part One (DRAFT)

Disclaimer: I haven't had any experience with Haskell, only OCaml, which is similar in many respects (type-inferencing and good pattern matching).. my Haskell syntax might be off at times, so bear with.

What you call extensionality is what I've known as currying. And a description of it will probably be easier if you talk more about type signatures and type inferencing.

In my opinion, the absolute coolest features of modern function languages (other than just being functional) are type inferencing and pattern matching. They are foreign concepts if your only programming background is Perl (especially type inferencing), so you should give them both a bit more time. Other cool features that you do mention are polymorphic types (Num a), and lazy evaluation of infinite objects (which I've never had any experience with).

As for pattern-matching, the absolute coolest demonstration of this is quicksort in 2 or 3 lines of Haskell (Update: code here). It shows how elegant and powerful pattern-matching can be... especially in Haskell, which has the most expressive matching out there.

WRT currying, it's easy to grasp by having a good understanding of what the type signatures mean -- plus it gives you a bit of insight into the language internals as well. The type signatures for multi-arg functions look like this:

sum x y = x + y sum :: Num a => a -> a -> a
Note that there are no parens in the signature a -> a -> a. This is a function of two variables, so why isn't the signature something like (a, a) -> a ?? Turns out that arrow is right-associative, so the type signature really means:
sum :: Num a => a -> (a -> a)
When you read it this way, you can see that sum is a function of one variable that returns another function of one variable. Under this view (the lambda-calculus view), currying is simply a natural side-effect:
increment = sum 1
sum 1 returned a function of one variable (a -> a), just like the type signature said it would! It's also important to notice that at this point, the type-inferencing engine may have specified the polymorphic type a to an Int type (don't know Haskell well enough to say for sure).

Function application on multiple arguments also makes sense under this interpretation as a left-associative operation:

sum 1 2 ## really means (sum 1) 2 ## which is (\y -> 1 + y) 2 ## 1 + 2
Multiple arguments and currying just come naturally by looking at functions from a lambda calculus context.

Also, MJD has a Perl-based talk about Strong typing that uses ML and gives a good example about how type inferencing helps the programmer catch bugs (I can attest to that).

Anyway, you're making me want to write an OCaml primer (and learn Haskell) ;) Good work so far!


Replies are listed 'Best First'.
Re^2: RFC: A Perlesque Introduction to Haskell, Part One (draft)
by FoxtrotUniform (Prior) on Jun 23, 2004 at 22:26 UTC
    What you call extensionality is what I've known as currying.

    Then I should do a better job.

    Extensionality says that the following two definitions are equivalent:

    foo = foldl1 f bar xs = foldl1 f xs -- note: xs is free on both sides
    The reason this works is that xs is free on both sides of bar: it's basically a placeholder that says "a list should go here". Both of these functions have type (a -> a) -> [a] -> a (modulo monomorphism-restriction annoyances).

    On the other hand, the function application

    foldl f -- note: not a definition (type is [a] -> a)
    is a curried expression: while foldl f xs returns a scalar, foldl f returns a function from lists to scalars. To me, currying means partial function application, and it's useful for producing ad-hoc functions where lambda is overkill.

    I like your point that currying is easier to understand when you know about type signatures, and thanks for the link to MJD's talk.

    F o x t r o t U n i f o r m
    Found a typo in this node? /msg me
    % man 3 strfry

Re^2: RFC: A Perlesque Introduction to Haskell, Part One (draft)
by runrig (Abbot) on Jun 23, 2004 at 23:46 UTC
    As for pattern-matching, the absolute coolest demonstration of this is quicksort in 2 or 3 lines of Haskell

    Just for the fun of it, and for comparision, here is what (I think) the equivalent perl would be (for numeric sorts, I don't know if Haskell has a separate character comparision operator like Perl):

    sub qs { return unless @_; my $x = shift; return qs(grep($_ < $x, @_)), $x, qs(grep($_ >= $x, @_)); }
    It can be done without the $x temp variable and the shift (saving one line), but then it's less readable IMO.

      Of course, since Perl allows in-place modification of arrays, you can implement quicksort much more efficiently than that in Perl, but that way is much more cool-looking.

      Incidentally, there is only one set of comparison operators in Haskell. To deal with the fact that Haskell is a strictly-typed language, there are multiple implementations of the same operator for different argument types. This is done throught the type classes that FoxtrotUniform mentioned. The determination of which implementation to use in a given expression is made at compile-time, which is both very powerful and very annoying. Getting Haskell programs to compile is rather difficult, but once they do they stand a pretty good chance of working the first time.

      Just for the hell of it:

      sub qs { local ($x, @xs) = @_ and return qs(grep($_ < $x, @xs)), $x, q +s(grep($_ >= $x, @xs)) or () }