RE: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
"Simon Marlow" <[EMAIL PROTECTED]> wrote, > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). I don't think, the point is the test for non-ambiguity. At least, Doitse's and my self-optimising parser combinator library will detect that a grammar is ambigious when you parse a sentence involving the ambiguous productions. So, you can check that by parsing a file involving all grammar constructs of the language. The point is much more the level of help that you get if your grammar happens to be ambiguous. My combinators at the moment just tell you that the grammar is ambiguous, but provide no help as to where and why. I think, this is similar for Doitse's combinators. Happy helps you much more in this situation. Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: MonadError and fundeps
Fri, 11 May 2001 14:40:27 +1000, Andrew J Bromage <[EMAIL PROTECTED]> pisze:
> What about mzero, though? What "natural definition" did you have
> in mind?
You are right, mzero is not as automatic as mplus. It surely means
'throwError something', but the value of something must be
determined separately.
'fail' belongs here too: I think it's always 'throwError something'
in practice.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonadError and fundeps
G'day all. On Thu, May 10, 2001 at 09:24:36PM +, Marcin 'Qrczak' Kowalczyk wrote: > BTW, another question: should MonadPlus instead of just Monad be > a superclass of MonadError? It has a natural definition in terms > of catchError. I can see how mplus has a "natural" definition (I can think of one or two circumstances where it's not semantically "natural", even if it is operationally "natural", but that's beside the point). What about mzero, though? What "natural definition" did you have in mind? Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
MonadError and fundeps
MonadReader, MonadWriter and MonadState classes have fundeps from the
monad type to the environment / output / state type (I added them
a few months ago).
MonadError doesn't. I thought that it's desirable to make a class with
more than one exception type, such that for example each catchError
would catch the corresponding throwError only, or even with simulation
of some subtyping policy.
Now I'm not sure that it was the right choice. I have an example when
having this fundep would be very helpful:
I am experimenting with building monadic parsing combinators from monad
transformers. In particular I already have a Parsec-like parsing monad
composed from pieces. It would be bad to hardwire the error type.
But without a fundep in MonadError overloaded functions can't be
written with MonadError in the context and without mentioning the
error type in their type (which would be impractical).
My workaround is to have a separate class, similar to MonadError but
with a fundep, with MonadError in its superclass, and with its own
instances. Fortunately this class can be empty, taking implementation
of pushing the error handling through monad transformers from
MonadError. But it would be more straightforward to use MonadError
directly.
I make use of the fundep in MonadState too. So I think that usually
one wants these fundeps.
Other argument for having a fundep in MonadError: monad transformers
provided by modules in package lang don't provide a monad which
could handle multiple errors anyway, and it would be impossible to
do it generically without overlapping instances. An instance would
have to recognize "its" error type, so it must work on a hardwired
type constructor.
If there was a fundep, the behavior of different error types can be
simulated by providing functions defined in terms of throwError and
catchError which throw a specific type or catch only a specific type
(this works only in the case where handling of all errors is done at
the same level of monad transformers, but I doubt that anyone would
make a monad without this property and still wanted to use generic
throwing and catching functions). This can be even done generically in
terms of classes which coerce a specific error type up or recognize
it, without touching all monads, as I am doing in the workaround in
the opposite direction.
What do you think? If nobody answers, I think I will add the fundep...
BTW, another question: should MonadPlus instead of just Monad be
a superclass of MonadError? It has a natural definition in terms
of catchError.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
Just out of curiosity, has anyone done any work at benchmarking the various parsers? I use Parsec pretty exclusivly since it comes with ghc and is pretty straightforward and lightweight to use. I am wondering what I am giving up in terms of speed by going that route, rather than Happy or the compiler toolkit non-monadic but pure-haskell parser? hmm... John On Thu, May 10, 2001 at 03:42:00PM +0100, Simon Marlow wrote: > > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). -- -- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. [EMAIL PROTECTED] -- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? I've used Happy instead of parser combinators because I wanted the additional global error-checking. I believe that the standard implementations of parser combinators will allow you to specify an ambiguous grammar, and return one of the multiple possible parses, without warning. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on > macros, I > have to ask: why use happy rather than monadic parsing? > Monadic parsing > allows you to avoid a whole additional language/compilation > step and work > in Hugs (where you don't have a makefile). What does Happy > buy you here? It buys you (a) speed, (b) confidence that your grammar is non-ambiguous, and (c) familiar BNF notation. On the down side, as you point out, you lose Haskell's abstraction facilities. I'd be willing to sacrifice (c) in order to write parsers in Haskell, but I don't think there's a combinator library that matches Happy in terms of speed (disclaimer: I haven't exhaustively tested them all, but given the tricks Happy does I'd be surprised). AFAIK none of the combinator libraries gives you (b). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
Combining two threads... Like macros and preprocessors, Happy generates code. I assume the justification for this is that hand-coding a parser in Haskell is presumed to be too difficult or that it is too hard to get the right level of abstraction (and therefore a macro-like facility is required). However, I've also used Hutton & Meijer style monadic parsers and found them extremely elegant, clean, and easy to use in both Haskell and Python (though in Python they were too slow for my xml application -- function call overhead is _very_ high in Python). I am not a parsing expert, but given the recent discussion on macros, I have to ask: why use happy rather than monadic parsing? Monadic parsing allows you to avoid a whole additional language/compilation step and work in Hugs (where you don't have a makefile). What does Happy buy you here? And generalizing from the above, since Monads/Arrows are types that describe a computation declaratively and Macros are functions that describe a computation procedurally, is it possible that, for any application of Macros, you can find a suitable Monad/Arrow? Or am I not understanding either well enough? -Alex- ___ S. Alexander Jacobson Shop.Com 1-646-638-2300 voiceThe Easiest Way To Shop (sm) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: Happy 1.10 released
"Simon Marlow" <[EMAIL PROTECTED]> wrote, > ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell An RPM package for x86 RedHat Linux[1] is now available at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.10-2.i386.rpm The matching source RPM is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.10-2.src.rpm Happy LALRing, Manuel [1] The binary has been build on RH7.0 with glibc2.2. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: Happy 1.10 released
> "Simon Marlow" <[EMAIL PROTECTED]> wrote, > > > ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell > > - > > It seems that the build system does not create a link from > `happy-' to `happy'. Is this intentional? No, it's a bug. I just noticed this weekend when I made the FreeBSD package. It's fixed in the repository now. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
