(b) i like my combinator grammars to be reversible, so that a single
grammar specification can be used for both parsing and
unparsing/pretty-printing. that means i have to define the
details myself anyway.
the latest such experiment is not necessarily the simplest variant,
for
Claus Reinke [EMAIL PROTECTED] wrote:
(b) i like my combinator grammars to be reversible, so that a single
grammar specification can be used for both parsing and
unparsing/pretty-printing. that means i have to define the
details myself anyway.
Oh cool - this is something I have
(b) i like my combinator grammars to be reversible, so that a single
grammar specification can be used for both parsing and
unparsing/pretty-printing. that means i have to define the
details myself anyway.
Oh cool - this is something I have wanted for a long time. Anything
contrary to monadic parsers, those continuation-based parsers
had *two* continuations, one for success, one for failure. and
that seemed to be a very natural match for the problem.
Two-continuations is a monad too, right?
yes, but my problem is not about giving them a monadic interface,
but
When you pretend you've never heard of monads or arrows, and
write down the types what do you get?
this question made me wonder whether i could still recall how i used
to write parsers before i heard of monads or arrows. it is difficult not
to fall back into the pattern of state transformer
Hi Claus. I am sympathetic with your comments regarding monads and
continuations. It's interesting to note that the original I/O system in
Haskell was based on streams and continuations. The continuation
version had two continuations in fact -- one for success and one for
failure. For
On Saturday 30 June 2007, Claus Reinke wrote:
The standard, naïve approach to monadic parsing is very nice, but
inefficient. So *please read* some material based on HuttonMeijer
approach, but don't stay there, read something more modern,
since we thereby seem to have left the phase of simple
Big Chris wrote:
http://www.cs.nott.ac.uk/~gmh/bib.html#monparsing
Hey, just to say, the first few pages of this explain monads really well.
Good reference :-)
It's the first introduction to monads I've seen that describes monads
directly, without using analogies, and manages to be both
Hi Gregory,
First post. I'm a newbie, been using Haskell for about a week and
love it. Anyway, this is something I don't understand. Parsers are
monadic. I can see this if the parser is reading from an input stream
but if there's just a block of text can't you just have the parser
call
Big Chris writes to Gregory, who posts:
... something I don't understand. Parsers are
monadic. I can see this if the parser is reading from an input stream
but if there's just a block of text can't you just have the parser
call itself recursively feeding the unparsed text down the recursion
The standard, naïve approach to monadic parsing is very nice, but
inefficient. So *please read* some material based on HuttonMeijer
approach, but don't stay there, read something more modern,
since we thereby seem to have left the phase of simple answers to
simple questions;-) i'd like to raise
On Sat, 30 Jun 2007, Claus Reinke wrote:
for all that i like monadic programming in general, i often feel
that it is biased towards handling only the success path well,
by offering built-in support for a single continuation only.
Certainly one path gets privileged over the others, I don't
On Jun 30, 2007, at 6:31 AM, Claus Reinke wrote:
has anyone else had similar experiences with expressive limitations
of monadic programming? things that one might be able to work
around, but that don't feel as natural or simple as they should be?
things that one hasn't been able to express at
Have you used Parsec?
i read about it when it came out, but i've always defined my own
combinators. in case you wonder, there are two reasons for this:
(a) the approximation of parsers as monads is close enough that a simple
type Parser m a = StateT String m a
gives us the basic
First post. I'm a newbie, been using Haskell for about a week and love it.
Anyway, this is something I don't understand. Parsers are monadic. I can see
this if the parser is reading from an input stream but if there's just a block
of text can't you just have the parser call itself
15 matches
Mail list logo
