[Haskell-cafe] Parsec without data declarations/AST

[Alexander Solla]

On Wed, Feb 20, 2013 at 1:09 AM, Sean Cormican <seancormican1 at gmail.com>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 <alex.solla at gmail.com>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 <alex.solla at gmail.com>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 <seancormican1 at gmail.com>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 at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130222/d8782561/attachment.htm>