On 21/04/2012 09:24 PM, Warp wrote:

>    The difference is that in eletronics the concepts feel very complicated
> when they try to explain them, while in Haskell they feel pretty trivial,
> yet the real understanding of it always escapes the layman.

Haskell is like Go: The rules are trivial. The game IS NOT.

As far as I know, the only way to really comprehend how to play Go is to 
actually... you know... play Go. Only then do you start to understand 
what the strategy and tactics are all about.

Haskell is similar. On the surface it looks pretty easy. The entire 
language consists of a handful of simple yet very general concepts. The 
way you APPLY those concepts to solve a problem? Well, that's an art. An 
art you only really learn by doing. (ESPECIALLY since half this stuff 
isn't written down anywhere, unfortunately.)

> For instance,
> I still don't understand what currying *really* is about, and every time
> I try to suggest "is like this?" the answer is "not really".

1. You can take a 5-argument function, pass it 2 argument, and get a 
3-argument function as the result.

Examples:

- (+1) takes a number and adds one to it.

- (5 ==) takes a number and returns True if it's 5.

- "map" takes a function and a list. "map abs" takes a list of numbers 
and returns a list of positive numbers.

2. Suppose foo is a 1-argument function. If you do "foo x y", then x is 
the argument to foo itself, and y is the argument to whatever foo 
returns (which must be a function).

Example: "head" takes a list and returns the first element. If you give 
it a list OF FUNCTIONS, then obviously the result of calling "head" will 
itself be another function. So it is legal to write

   head function_list 7

It looks like we're calling "head" with 2 arguments, yet "head" is a 
1-argument function. But what is /really/ happening is that 
function_list is the argument to "head", and the 7 is then passed as an 
argument to whatever "head" RETURNS.

(Notice how the result of calling "head" would not normally be a 
function. There are lots of other examples of where a result wouldn't 
usually be a function, but under sufficiently unusual circumstances it is.)

3. If you write a class which works one way for functions, and another 
way for non-functions, then you can polymorphically handle functions 
with ANY NUMBER OF ARGUMENTS. If it weren't for currying, you'd have to 
write a separate version of the class for every size of function. And 
that would violate DRY.

For example, QuickCheck allows you to turn any function into a "test", 
provided that

- The function returns true/false values.

- All of the function's arguments support automated test data generation.

In particular, it works for 0-argument functions (i.e., constants), 
unary functions, binary functions, ternary functions, etc. Basically 
there's a class instance that says "this is how you test a Bool", and 
another that says "this is how you test a function that takes one 
argument and returns something testable". A Bool is testable, but so is 
a 1-argument function. And, by induction, an N-argument function.

>    And then they wonder why functional programming isn't mainstream.

Oh, I think that's due to a little bit more than just the ethereal 
nature of advanced concepts. It's probably more "man, this stuff is too 
different to what I'm used to; I can't be bothered with it". That and 
(most especially in the case of Haskell) a supreme lack of quality 
documentation.

Post a reply to this message