Quentin Moser wrote:

On Sat, 11 Apr 2009 02:02:04 -0700 Michael Mossey wrote:

This is a matter of good coding style (in the sense of modularity, maintanability, etc.).

As you've seen it, the authors have first started with a (>>?) function that allows them to combine Maybes, that is to combine functions with a possibility of error. ...

Thanks for the detailed explanation. I like how you show that the original >>? function, and the method of signaling either an error or a result, could have been written with ==> notation. But, I'm still confused on a point. Let me put it this way. The authors wrote: -- file: ch10/Parse.hs -- import the Word8 type from Data.Word parseByte :: Parse Word8 parseByte = getState ==> \initState -> case L.uncons (string initState) of Nothing -> bail "no more input" Just (byte,remainder) -> putState newState ==> \_ -> identity byte where newState = initState { string = remainder, offset = newOffset } newOffset = offset initState + 1 Why couldn't they have avoided getState by writing parseByte = Parse ( \initState -> case L.unconcs (string initState) of ... ... newOffset = offset initState +1 ) ...because a parser is by definition a function that takes ParseState as its input. I understand you are saying that in future chapters they may introduce new capabilities that fit within this framework, so maybe that's what I'm not seeing. Maybe they will redefine getState (or something equivalent) so that it does more than grab the unchanged state from the Parse. But I'm curious to know if my second implementation works the same as the first, in theory. Thanks

Daniel Fischer wrote:

In a real library, the constructor Parse would not be exported, to allow later changing the implementation of the Parse type without breaking user code. So user code like parseByte cannot access the constructor and must use the exported API (getState, putState, identity, bail, ...).

thanks for the point, I get it. One other question. Later in the chapter they define peekByte as follows: -- file: ch10/Parse.hs peekByte :: Parse (Maybe Word8) peekByte = (fmap fst . L.uncons . string) <$> getState Here they are accessing the 'string' field of the state. So whomever writes this function needs to have the accessor functions. At this point I'm wondering how much state is really getting hidden. Or maybe peekByte would only be written inside the original library. I was just playing around and discovered you can choose to export the accessor functions or not. Let's say we have -------- module Mod where data What = What { acc :: Int64 } -------- now in a separate module we write: ------------------- -- All fine: import Mod x1 = What 3 x2 = What { acc = 3 } x3 = acc x1 --------------- Now we revisit the first module and write module Mod ( What(What) ) where Now, import Mod x1 = What 3 -- Fine x2 = What { acc = 3 } -- Error x3 = acc x1 -- Error So apparently this exports the constructor but not the accessor fields. The item can be constructed in the normal way, but not in record syntax way. Finally module Mod ( What(acc) ) where --> This exports the accessors which can be used to access, but not to construct module Mod (What(..)) where --> export everything So the lesson is, if we are going to allow users to write functions like peekByte, we have to export the accessor functions, but not necessarily any constructors.

Am Samstag 11 April 2009 19:04:22 schrieb Quentin Moser:

On Sat, 11 Apr 2009 09:37:53 -0700

Michael Mossey wrote:

...

One other question. Later in the chapter they define peekByte as follows:

-- file: ch10/Parse.hs peekByte :: Parse (Maybe Word8) peekByte = (fmap fst . L.uncons . string) <$> getState

Here they are accessing the 'string' field of the state. So whomever writes this function needs to have the accessor functions. At this point I'm wondering how much state is really getting hidden. Or maybe peekByte would only be written inside the original library.

The point is not so much hiding the state, but hiding the details of the Parse type. newtype Parse a = Parse { runParse :: ParseState -> Either String (a,ParseState) } is, except for the names, StateT ParseState (Either String) a. What peekByte assumes is that there is an instance MonadState ParseState Parse where... , implicitly at least. peekByte won't break if the implementation of Parse is changed, as long as that is maintained. If you look at the haddock docs for Parsec, you'll see that there the State is exposed while GenParser is only exported as an abstract type, allowing the details to be changed if deemed advantageous.

Even before worrying about the accessor functions, a parsing library would in the first place not even export getState, putState, or the ParseState type. It would instead provide functions like parseByte and peekByte as primitives from which all complex parsers will be built.

Parsec does: getParserState setParserState