On Oct 31, 2010, at 17:15 , Nils Schweinsberg wrote:
Am 31.10.2010 16:53, schrieb Vo Minh Thu:
I can't really tell from your description, but maybe this is because
of the way Parsec works when it deals with alternatives. When you
combine several parsers with e.g. '|' or 'choice', an
On 31/10/2010 04:15 PM, Nils Schweinsberg wrote:
This is exactly what gives me headaches. It's hard to tell where you
need try/lookAhead and where you don't need them. And I don't really
feel comfortable wrapping everything into try blocks...
I vaguely recall somebody mentioning a parser
On 1 November 2010 22:18, Andrew Coppin andrewcop...@btinternet.com wrote:
I vaguely recall somebody mentioning a parser library on Hackage where
try is the default behaviour and you turn it off explicitly, rather than
turning it on explicitly. Apparently this is much more intuitive. But
Hi!
I'm having a really hard time to write a correct parser for a small
language I've developed. I have been trying to write a parser using
parsec, but always get a lot of error messages like unexpected \n,
expected ..., new-line or... when trying to run the parser. Then I read
about the
I don't know if you've already used it, but Parsec includes some kind of a
lexer through the
Languagehttp://hackage.haskell.org/packages/archive/parsec/3.1.0/doc/html/Text-Parsec-Language.htmland
Tokenhttp://hackage.haskell.org/packages/archive/parsec/3.1.0/doc/html/Text-Parsec-Token.htmlmodules.
2010/10/31 Nils Schweinsberg m...@n-sch.de:
Hi!
I'm having a really hard time to write a correct parser for a small language
I've developed. I have been trying to write a parser using parsec, but
always get a lot of error messages like unexpected \n, expected ...,
new-line or... when trying
If you use the Language and Token modules, Parsec gives you something
close to a lexer / parser separation _but_ you can drop down to
character level parsers if you want to - this is very handy. There are
some caveats though - for instance, the number parsers from the Token
module follow Haskell's
On 31 October 2010 15:55, Stephen Tetley stephen.tet...@gmail.com wrote:
ecessary.
You can also write separate parsers this is covered in the (pdf)
Parsec manual available from Daan Leijen's old home page, however I
usually avoid this as it seems rather cumbersome.
D'oh. I meant separate
Am 31.10.2010 16:50, schrieb Ozgur Akgun:
I don't know if you've already used it, but Parsec includes some kind of
a lexer through the Language
http://hackage.haskell.org/packages/archive/parsec/3.1.0/doc/html/Text-Parsec-Language.html
and Token
Am 31.10.2010 16:53, schrieb Vo Minh Thu:
I can't really tell from your description, but maybe this is because
of the way Parsec works when it deals with alternatives. When you
combine several parsers with e.g. '|' or 'choice', an alternative
that can consume some input but fails will make the
On 31 October 2010 16:15, Nils Schweinsberg m...@n-sch.de wrote:
This is exactly what gives me headaches. It's hard to tell where you need
try/lookAhead and where you don't need them. And I don't really feel
comfortable wrapping everything into try blocks...
I always thought this was an
On 31 October 2010 16:23, Ozgur Akgun ozgurak...@gmail.com wrote:
Am I missing something?
Left factoring! :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 31 Oct 2010, at 16:15, Nils Schweinsberg wrote:
Am 31.10.2010 16:53, schrieb Vo Minh Thu:
So you have to either factorize you parsers or use
the 'try'.
This is exactly what gives me headaches. It's hard to tell where you
need try/lookAhead and where you don't need them. And I don't
- Is this a valid approach?
It is possible that your Parsec lexer will need to see the entire
input before it delivers any tokens at all to the Happy parser. This
might cause a space problem, depending on how large your inputs are
likely to be.
- What is your workflow on parsing
On 31 October 2010 16:53, Nils Schweinsberg m...@n-sch.de wrote:
Am 31.10.2010 17:27, schrieb Stephen Tetley:
Left factoring! :-)
Stupid question: Whats that? :)
Actually a good question...
Its a standard grammar transformation - if you have two alternative
productions that share a common
Nils Schweinsberg wrote:
This is exactly what gives me headaches. It's hard to tell where you
need try/lookAhead and where you don't need them. And I don't really
feel comfortable wrapping everything into try blocks...
In my experience, try blocks should only be used at the very inner
most
16 matches
Mail list logo
