Dear Cafe,
I am trying to implement[1] parsec in go using the Monadic Parser
Combinators paper [2] . I've been able to implement plus bind and
many
While doing the implementation - I looked at bind closely
bind :: Parser a - (a - Parser b) - Parser b
p `bind` f = \inp - concat [f v inp' |
Think about this: if you always take only the first element, why do you
need lists at all?
Roman
* C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
Dear Cafe,
I am trying to implement[1] parsec in go using the Monadic Parser
Combinators paper [2] . I've been able to implement plus
To: C K Kashyap
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Parsec question
Think about this: if you always take only the first element, why do you
need lists at all?
Roman
* C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
Dear Cafe,
I am trying to implement[1] parsec in go using
Because of laziness, you do in a sense only take the first successful
value. When I've made parser combinators for Python before, I've used
either generators or exceptions to get lazy evaluation, since computing the
whole list of possibilities for each bind would ruin the running time of
the
the complete match.
regards,
Kashyap
Sent from my Windows Phone
From: Roman Cheplyaka
Sent: 24/07/2013 8:19 PM
To: C K Kashyap
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Parsec question
Think about this: if you always take only the first element, why do you
need lists at all?
Roman
Thanks Kyle,
My initial implementation was evaluating the whole list - the current one
though just returns the first successful result. Anyway, I think I need the
backtracking - I would want the aaa as the result :)
I will now explore using go-routines to implement laziness.
Thank you so much
/2013 8:19 PM
To: C K Kashyap
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Parsec question
Think about this: if you always take only the first element, why do you
need lists at all?
Roman
* C K Kashyap ckkash...@gmail.com [2013-07-24 19:56:29+0530]
Dear Cafe,
I am trying
I am a new Parsec user, and having some trouble with a relatively
simple parser.
The grammar I want to parse contains tags (not html) marked by
angle brackets (e.g., some tag), with arbitrary text (no angle
brackets allowed) optionally in between tags.
Tags may not nest, but the input must begin
On Tue, Sep 28, 2010 at 10:35 PM, Peter Schmitz ps.hask...@gmail.com wrote:
I am a new Parsec user, and having some trouble with a relatively
simple parser.
The grammar I want to parse contains tags (not html) marked by
angle brackets (e.g., some tag), with arbitrary text (no angle
brackets
2009/4/17 Michael P Mossey m...@alumni.caltech.edu:
I want to write a parser that can read a file with this format: the file has
sections which are demarcated by keywords. Keywords always begin with two
forward slashes and consist of letters, digits, and underscore. The text can
be anything,
Here's what I've got so far.
-- Text is considered everything up to //. However, the problem
-- is that this consumes the //.
parseText = manyTill anyChar (try (string //))
-- Because the // is already consumed, parseKeyword just grabs
-- the available letters.
parseKeyword :: Parser String
You can use 'notFollowedBy' (probably with 'many1' and 'try').
Something like (untested):
notFollowedBy (try $ string //)
Thu
2009/4/17 Michael Mossey m...@alumni.caltech.edu:
Here's what I've got so far.
-- Text is considered everything up to //. However, the problem
-- is that this
My confusion is that text is by definition followed by // or eof.
minh thu wrote:
You can use 'notFollowedBy' (probably with 'many1' and 'try').
Something like (untested):
notFollowedBy (try $ string //)
Thu
2009/4/17 Michael Mossey m...@alumni.caltech.edu:
Here's what I've got so far.
--
2009/04/17 minh thu not...@gmail.com:
2009/04/17 Michael Mossey m...@alumni.caltech.edu:
I wonder how I can get the manyTill to be happy with eof
before finding the //? I tried
parseText = manyTill anyChar (try (string //) | eof)
but got a type error.
You can use 'notFollowedBy' [...]
Jason Dusek wrote:
2009/04/17 minh thu not...@gmail.com:
2009/04/17 Michael Mossey m...@alumni.caltech.edu:
I wonder how I can get the manyTill to be happy with eof
before finding the //? I tried
parseText = manyTill anyChar (try (string //) | eof)
but got a type error.
You can use
I've just about got this parser working, but wondering about something. Turns
out I need try inside the lookahead here.
parseText :: Parser String
parseText = manyTill anyChar $ lookAhead (try (string //))
Without try, if I give it an input with a single slash, like
some/text
It stops with
Am Samstag 18 April 2009 01:33:44 schrieb Michael P Mossey:
I've just about got this parser working, but wondering about something.
Turns out I need try inside the lookahead here.
parseText :: Parser String
parseText = manyTill anyChar $ lookAhead (try (string //))
Without try, if I give it
I want to write a parser that can read a file with this format: the file has
sections which are demarcated by keywords. Keywords always begin with two
forward slashes and consist of letters, digits, and underscore. The text can be
anything, including special characters. For instance:
Hi all,
I'm rather new to Haskell and I'm diving right into the deep end
writing a parser using Parsec.
In particular I'm using Text.ParserCombinators.Parsec.Language to do
some of the heavy lifting and have this:
import qualified Text.ParserCombinators.Parsec.Language as L
import
Erik de Castro Lopo wrote:
qualifiedIdentifier :: CharParser st [ String ]
Ahh, figured it out myself:
qualifiedIdentifier :: CharParser st [ String ]
qualifiedIdentifier = do
i - identifier
r - dotIdentifier
return (i : r)
where
Hi,
Fairly new to Haskell and trying some parsec. (Also, new to
parsers/interpreters)
I had come up with this, which works, but I can't help thinking there's
a better way :)
| newtype Identifier = Identifier String
newtype Literal = StringLiteral String -- to be extended later
data
On Thu, Jun 21, 2007 at 03:34:54PM +0930, Levi Stephen wrote:
Is there a way through combining types/parsers that the double do
block in primary could be avoided?
I understand it's necessary right now because the parsers identifier
and stringLiteral return different types, so I can't just
I find it's good for the soul to remember what the do notation is doing for us.
Also I'm with Einstein on You do not really understand something
unless you can explain it to your grandmother :)
Personally I think (in this instance) your three 'Parser a' functions
read nicer as:
primary =
On 6/21/07, Dave Tapley [EMAIL PROTECTED] wrote:
primary = (identifier = (return . PrimaryIdentifier)) | (stringLiteral
= (return . PrimaryLiteral))
identifier = (many1 letter) = (return . Identifier)
stringLiteral = (char '\'') (manyTill anyChar (char '\'')) = (return .
StringLiteral)
I
Thomas Conway wrote:
p `with` f = p = (return . f)
so I can write
primary = (identifier `with` PrimaryIdentifier) | (stringLiteral
`with` PrimaryLiteral)
I would write
primary = PrimaryIdentifier `fmap` identifer
| PrimaryLiteral`fmap` stringLiteral
(I prefer fmap to liftM but
Levi Stephen wrote:
newtype Identifier = Identifier String
newtype Literal = StringLiteral String -- to be extended later
data Primary = PrimaryLiteral Literal | PrimaryIdentifier Identifier
primary = do {
i - identifier;
return $ PrimaryIdentifier i; }
| do {
l -
Tillmann Rendel wrote:
My self-defined monadic combinator of choice to use with parsec is
a ~ b = a = \x - b return x
It works like (), but returns the result of the first instead of the
result of the second computation. It is kind of an alternative for
between:
between lparen rparen
Greetings.
I'd like to write a parser that takes some Haskell source code and
seperates it into two piles - comments, and everything else.
I have a parser that recognises single-line comments, and another that
recognises multi-line comments. What I'd like to do is make a big parser
that
Andrew Coppin [EMAIL PROTECTED] writes:
I have a parser that recognises single-line comments, and another that
recognises multi-line comments. What I'd like to do is make a big parser
that returns [Either String String], which all the comments in one side
and all the rest in the other
Malcolm Wallace wrote:
Andrew Coppin [EMAIL PROTECTED] writes:
Any hints?
wholething = many comment
comment = do
fmap Left $ (linecomment `onFail` nestedcomment)
`onFail`
fmap Right $ noncomment
Haskell: The language of truely scary people(tm) :-}
I'm trying to use parsec for parsing a custom input stream. As far as I
understood the manual correctly I need to define the primitive parser:
type MyParser a = GenParser (SourcePos,Tok) () a
mytoken :: (Tok - Maybe a) - MyParser a
mytoken test
= token showToken posToken testToken
where
Am Montag, 9. Januar 2006 12:52 schrieb Gerd M:
I'm trying to use parsec for parsing a custom input stream. As far as I
understood the manual correctly I need to define the primitive parser:
type MyParser a = GenParser (SourcePos,Tok) () a
mytoken :: (Tok - Maybe a) - MyParser a
mytoken
Hi,
I am trying to develop a parser with the Parsec library. At some point I
need to do something with parser state, say, convert it to a string.
I declared the type for the parser:
type TParser a = GenParser Token (FiniteMap String Declaration) a
The FiniteMap (which is the user state) is
On Sun, Mar 20, 2005 at 03:32:38PM -0500, Dimitry Golubovsky wrote:
type TParser a = GenParser Token (FiniteMap String Declaration) a
The FiniteMap (which is the user state) is expected to be updated during
parsing whus building some internal lookup table.
and in one of the parsing
On Fri, 19 Nov 2004 14:28:07 + (UTC), John Goerzen
[EMAIL PROTECTED] wrote:
Hi,
I'm porting a parser over from an OCamllex/Ocamlyacc version and I'm
using Parsec for both the tokenizer and the resulting token stream parser.
I have both of them working fine, but now my question is: how do
? Are you
talking about reporting the position of lexical or parse errors? (If so,
Parsec supports this quite well.)
Alistair.
-Original Message-
From: John Goerzen [mailto:[EMAIL PROTECTED]
Sent: 19 November 2004 14:28
To: [EMAIL PROTECTED]
Subject: [Haskell-cafe] Parsec question
Hi
On Fri, Nov 19, 2004 at 02:56:38PM -, Bayley, Alistair wrote:
I've also used Parsec for separated lexer + parser and currently have
something like this to invoke them:
testParse inputString = do
case (parse myLexer inputString) of
Left err - fail (lexical error: ++ err)
37 matches
Mail list logo