[Haskell-cafe] Newbie: Is‘type’ synonym hiding two much?

[Ian Lynagh]

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