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'.

<Antti-Juhani Kaijanaho wrote> 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. At least something to know :) I'll try to remeber this idiom.

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:

<Antti-Juhani Kaijanaho wrote> I'm not sure why you feel the need to talk about runtime. This all happens at compile time. I wrote "runtime" because I didn't know how in own word to term inteprepter (GHCi) and compiler (GHC). Both of them will deal with this task/

2. Should I search through main and imported modules for treacherous 'type' constructs?

<Antti-Juhani Kaijanaho wrote> 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. I see now, got it! Thanks.

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'.

Yet, function definition given in the book is:

succeed val inp = [(val, inp)]

<Ian Lynagh wrote> It's common to instead write this as succeed :: b -> Parse a b succeed val = \inp -> [(val, inp)] so the definition fits the type signature better. Yes, that make more sense to me - function that returns a "customized" function <Ian Lynagh wrote> The main advantage of the synonym is when you are /using/ the Parser library, so you can put Parser String's in sequence etc without needing to know that internally they're implemented as a function. Do you mean that if insted of type sysnonym I would use ADT built with 'data': data Parser a b = Parser (a -> [(b, [a])]) succeed :: b -> Parse a b succeed val = Parser (\inp -> ...) then I would not be able to put "put Parser String's in sequence etc without needing to know that internally they're implemented as a function" ? Anyway, I will try to implement this version of Parser as well. <Bernie Pope wrote> I think the main issue here is that from the "user's perspective" the Parse type should be (or is) abstract. Users of Parse should not really have to know how it is internally implemented. But implementors of Parse will (of course) be concerned with those details. How you look at the Parse type depends on which camp you belong to: implementor or user. Very good observation Bernie, thanks. Yet I need to play more with Parser type to justify it for this case :) Thanks guys for all your feedback! It really helps!