RE: [Haskell-cafe] Newbie: Is'type' synonym hiding two much?

[Bernie Pope]

Dmitri writes:

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

> Yet, function definition given in the book is:
> succeed val inp = [(val, inp)]

I may not answer all your questions, but I will make a few observations.

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.

The definition of succeed is the concern of the implementor, since it is a
primitive of the Parse library. So an implementor will know that Parse is
internally a function type.

It may be nicer if they wrote:

   succeed val = \inp -> [(val, inp)]

But that is a matter of style.

If the library is written correctly, the user should not care about what the
Parse synonym unfolds to. They will mostly care about how to build "atomic"
parsers, how to combine parsers together to form new ones, and how to run
parsers. It is very liberating for the user if they don't have to know what
goes on inside the Parse type.

Perhaps the textbook focuses mostly on the implementor's point of view,
where you are forced to be aware of the gory details.

Haskell uses abstract types in other places, most notably the IO type. There
is quite a bit of complexity hidden in that type, but its user interface is
relatively simple. 

If Haskell has taught me anything, it's that abstraction rules!

Cheers,
Bernie.