- Glasgow-haskell-users

RE: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by Simon Marlow 12 May '01

12 May '01

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

5 4

RE: GHCi turned upside down?
by Simon Marlow 11 May '01

11 May '01

> GHCi allows us to mix fixed compiled and dynamic interpreted code to > be run from what I presume is dynamic interpreted code - the command > prompt. Would it be possible to run dynamic interpreted code from > a compiled program? I'm hoping the answer is "Yes, because > this is what > GHCi does", the only problem being to clean up the syntax and document > it. It's certainly possible, but bear in mind that you'd have to link in essentially the whole of GHCi into your program in order to do it! But one of the things on our wish list is to have a clearly defined interface to the underlying compilation/session manager, (i.e. what we've been calling the HEP, or Haskell Execution Platform). This would allow you to plug in new user interfaces, make interpreted COM objects, and in general have Haskell compilation/execution services available from a Haskell API. There's still work to do in deciding exactly what this API should look like, though. Cheers, Simon

1 0

MonadError and fundeps
by Marcin 'Qrczak' Kowalczyk 11 May '01

11 May '01

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 * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

3 6

GHCi turned upside down?
by George Russell 11 May '01

11 May '01

GHCi allows us to mix fixed compiled and dynamic interpreted code to be run from what I presume is dynamic interpreted code - the command prompt. Would it be possible to run dynamic interpreted code from a compiled program? I'm hoping the answer is "Yes, because this is what GHCi does", the only problem being to clean up the syntax and document it. I'm afraid I haven't been following the FFI debate lately but perhaps we could steal some of the FFI's syntax for declaring types of imported entities. The difference (I'm not sure if this is a difference with the latest with the latest FFI version) would be that the source file/string (and perhaps function name) need to vary dynamically, which means also that of course it needs to be done below top level, and invoke an IO action. So we might try something like runMain :: FilePath -> IO () runMain sourcePath = do source <- readFile sourcePath foreign import ghci source "main" main :: IO () main which would read the file "sourcePath", interpret it as Haskell, and run the "main" action therein. This isn't meant to be a polished proposal, just an idea for something which might be nice to have around in the future.

1 0

Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
by cwitty＠newtonlabs.com 10 May '01

10 May '01

"S. Alexander Jacobson" <alex(a)shop.com> 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

1 0

ANNOUNCE: Happy 1.10 released
by Simon Marlow 10 May '01

10 May '01

ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell ----------------------------------------------------------------- I'm pleased to announce version 1.10 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.10 (the previous full release): * bugfixes, and minor performance improvements, * most of the examples work again. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08 or 5.00 recommended), and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to simonmar(a)microsoft.com.

3 3

RE: ANNOUNCE: Happy 1.10 released
by Simon Marlow 10 May '01

10 May '01

> "Simon Marlow" <simonmar(a)microsoft.com> 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-<version>' 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

1 0

Profiling on Windows.
by Theodore Norvell 06 May '01

06 May '01

Hi. I'm using ghc version 4.08.2 on windows NT. I tried compiling my program with -prof -auto-all. It runs up until input is required (from stdin) and then crashes claiming "The instruction at 0x0 referenced memory at 0x0. The memory could not be read". Is there a known problem with profiling on NT systems? Cheers, Theodore Norvell ---------------------------- Dr. Theodore Norvell theo(a)engr.mun.ca Electrical and Computer Engineering http://www.engr.mun.ca/~theo Engineering and Applied Science Phone: (709) 737-8962 Memorial University of Newfoundland Fax: (709) 737-4042 St. John's, NF, Canada, A1B 3X5

1 0

RE: Building nhc98-1.02 with ghc-5.00
by Simon Peyton-Jones 04 May '01

04 May '01

I've committed a fix. Simon | -----Original Message----- | From: Simon Marlow | Sent: 27 April 2001 10:19 | To: Wolfhard Buß; nhc-users(a)cs.york.ac.uk | Cc: glasgow-haskell-users(a)haskell.org | Subject: RE: Building nhc98-1.02 with ghc-5.00 | | | > the building of nhc98-1.02 with ghc-5.00 aborts | > with the message: | > | > Main.hs:8: | > Failed to find interface decl for | > `PrelGHC.(#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, | > ,,,,,,,,,,,,,,,,,,,,,,,#)' | > from module `PrelGHC' | > | > Any hints for interpretation? | | Workaround: compile this particular module without -O, or | with -fno-cpr. | | Cheers, | Simon | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

Windows InstallShield updated
by Reuben Thomas 03 May '01

03 May '01

I've just uploaded a better Windows InstallShield for GHC that fixes a problem with the last one, but more importantly, hides the Cygwin binaries it installs in ghc-4.08.2/extra-bin, so that they do not interfere with, and are not intefered with by, any installation of Cygwin you may have on your system. Incidentally, I have also fixed a small problem in the Happy InstallShield, so if you couldn't get it to work, try downloading again. -- http://sc3d.org/rrt/ "Reality is what refuses to disappear when you stop believing in it" - Philip K. Dick

1 0