- Glasgow-haskell-users

Windows binary installation for GHC 5.00
by Bernd Holzmüller 16 May '01

16 May '01

Is there any prediction for when the Windows (NT) binary distribution for GHC 5.00 will be available? I would not want to install GHC5.00 from the source distribution in case the binary distribution is going to be released "soon". Anyway, I would expect getting an appropriate note via the glasgow-haskell-users mailing list. Bernd Holzmüller

1 0

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

14 May '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > I didn't say that this works for any kind of parser > combinator, I merely said that it works Doitse's and mine. > Both implement SLL(1) parsers for which - as I am sure, you > know - there exists a decision procedure for testing > ambiguity. More precisely, whenever the library can build > the parse table, the grammar must be non-ambigious. As the > parse table construction is lazy, this covers only the > productions exercised in that particular run, which is why I > said that you need a "file involving all grammar constructs > of the language." Nothing magic here. Wow. Clearly I haven't spent enough time looking at your parser systems. I apologize for my incorrect assumptions and statements. Carl Witty

1 0

Compile problems with ghc-5.0
by Gérard Milmeister 13 May '01

13 May '01

I use Redhat 6.2. The binary install is ok, but when I compile ghc-5.0 from source using ghc-5.0, I get the following error after 'make all': ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc ../../../ghc/utils/hsc2hs/hsc2hs-inplace: /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin: No such file or directory Furthermore, most available libraries seem to be uncompilable with ghc-5.0, e.g. c2hs and gtk2hs. -- Gérard Milmeister Tannenrauchstr. 35 8038 Zürich

3 2

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

13 May '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > 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. Sorry, doesn't work. Where do you get this "file involving all grammar constructs of the language"? If such an approach worked, you could use it to determine whether an arbitrary context-free grammar was ambiguous; but this problem is undecidable. Carl Witty

3 2

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