On Thu, Mar 22, 2007 at 06:13:00PM +0300, Dmitri O.Kondratiev wrote:
F :: a -> b -> c
Is the same as:
F :: a -> (b -> c)
Correcting the typo (use f, not F), these mean the same thing.
And means either:
- a function 'f' of one argument of type 'a' that returns a function of type (b -> c), or it can also be interpreted as: - a function 'f' of two arguments of type 'a' and 'b' returning value of type 'c'
Yes. The essential point to understand that these interpretations *are the same*.
Now, in the 17.5 section of a book one may see the following declarations:
succeed :: b -> Parse a b
*Before looking at 'succeed' function definition* one may think that 'succeed' is a function of *one* argument of type 'b' that returns object of type 'Parse a b'.
That's what it is. However, without looking at the definition of Parse a b, you can't tell whether that is a function or not, and therefore all you can say about succeed is that it takes *at least* one argument.
Then I do this substitution *myself as a Haskell runtime* and get in the result the following declaration of a * real function that Haskell runtime* works with:
I'm not sure why you feel the need to talk about runtime. This all happens at compile time.
2. Should I search through main and imported modules for treacherous 'type' constructs?
They are not treacherous. But yes, if you want to know what a type stands for, you need to look it up. The "treacherous" thing here is that in Haskell, returning a function is the same as taking one more parameter. This may feel strange at first, but it is a very important idiom and you do need to learn to live with it if you want to use Haskell.
3. Where, in this case goes implementation abstraction principle? Why I must provide *all* the details about function argument type structure in order to understand how this function works?
"type" is just notational convenience. If you want abstraction, use "newtype" or "data".