On Thu, Mar 22, 2007 at 06:13:00PM +0300, Dmitri O.Kondratiev wrote:
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)]
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.
1. Should I work every time as a macro translator when I just see *!any!* function declaration?
If you are going to be dealing with the actual definitions of something like Parser then you do need to know what the synonym is, yes. Your implementation should be able to help you, e.g. in ghci: Prelude> :i ReadS type ReadS a = String -> [(a, String)] -- Defined in Text.ParserCombinators.ReadP 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.
2. Should I search through main and imported modules for treacherous 'type' constructs? 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?
If you want abstraction then you need to use newtype or data to declare the type. e.g. if you had newtype Parser a b = Parser (a -> [(b, [a])]) then succeed :: b -> Parse a b succeed val inp = ... would be rejected by the compiler. Instead you would have to write succeed :: b -> Parse a b succeed val = Parser (\inp -> ...) Thanks Ian