On Wed, Feb 20, 2013 at 1:09 AM, Sean Cormican <[email protected]>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 <[email protected]>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 <[email protected]>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 >>> <[email protected]>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 >>>> [email protected] >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >> >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
