Come to think of it, a parsec parser already wraps over Either, so if all you want to do is check if a result is valid, you can abuse the Either semantics so that your type is: Parser () -- the parser which returns nothing on success or an error on failure. On Tue, Feb 19, 2013 at 3:20 PM, Alexander Solla wrote:

If all you want to do is check that the code is valid (i.e., you aren't going to interpret the code), you can just return a Bool. If you want to interpret it, but don't want to have a Stmt type, you can return IO () actions. In that case, the parser's type will be

Parser (IO ())

I think an algebraic AST (or even a functorial/monadic one) will help separate concerns, and will eventually help when it comes time to optimize your compiler. It really isn't as much boilerplate as it looks like (in fact, there's hardly any boilerplate if you target free monads and interpret those in IO), and you get the type safety for which Haskell is well-known.

On Tue, Feb 19, 2013 at 3:02 PM, Sean Cormican wrote:

...

I have been trying to create a parser for a functional programming language, but there is no need to create an AST but merely check that the code is valid according to the grammar.

In the following tutorial I have been trying to take some pointers from, data declarations are used to create an AST for the language, There is, as I understand a way to parse the language without an AST.

http://www.haskell.org/haskellwiki/Parsing_a_simple_imperative_language

My question is what should the type signatures for example parseFile function instead of "Stmt" accept as input if the parser is to accept Strings and numerical expressions alike ?

Thanks for any help, Seán

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Feb 20, 2013 at 1:09 AM, Sean Cormican wrote:

Thanks that is exactly what I was looking for, one further question I might ask is how I might allow for either a integer or a string to be parsed. As it is now I get a complaint if I try and parse either a String or an Integer without creating a data declaration for say "Express" containing:

data Express = ID String | Num Integer

is there a way around this without a need for a data declaration? As far as I know the parser will only accept (in this case) either Strings or Integers but not both, for example:

expr8 = name <|> number

name :: String number :: Integer

I don't see how expr8 type checks at all. (<|>) is for "alternative" functors. In any case, I think we're using vocabulary differently. To me, a parser "accepts" strings and "returns" whatever value was constructed by parsing the string. So, if you want to "return" a value that could be a String or an Integer, you'll have to return (Either String Integer) or (Either Integer String) or make an algebraic data type. Note that Either a b is an algebraic data type defined by:

data Either a b = Left a | Right b

will cause an error unless name and number are created using the value constructors ID and Num and are both the data type Express. Anybody have any thoughts on this ?

Thanks in Advance, Seán

On Tue, Feb 19, 2013 at 11:22 PM, Alexander Solla wrote:

...

Come to think of it, a parsec parser already wraps over Either, so if all you want to do is check if a result is valid, you can abuse the Either semantics so that your type is:

Parser () -- the parser which returns nothing on success or an error on failure.

On Tue, Feb 19, 2013 at 3:20 PM, Alexander Solla wrote:

...

If all you want to do is check that the code is valid (i.e., you aren't going to interpret the code), you can just return a Bool. If you want to interpret it, but don't want to have a Stmt type, you can return IO () actions. In that case, the parser's type will be

Parser (IO ())

I think an algebraic AST (or even a functorial/monadic one) will help separate concerns, and will eventually help when it comes time to optimize your compiler. It really isn't as much boilerplate as it looks like (in fact, there's hardly any boilerplate if you target free monads and interpret those in IO), and you get the type safety for which Haskell is well-known.

On Tue, Feb 19, 2013 at 3:02 PM, Sean Cormican wrote:

...

I have been trying to create a parser for a functional programming language, but there is no need to create an AST but merely check that the code is valid according to the grammar.

In the following tutorial I have been trying to take some pointers from, data declarations are used to create an AST for the language, There is, as I understand a way to parse the language without an AST.

http://www.haskell.org/haskellwiki/Parsing_a_simple_imperative_language

My question is what should the type signatures for example parseFile function instead of "Stmt" accept as input if the parser is to accept Strings and numerical expressions alike ?

Thanks for any help, Seán

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe