May 2001 - Glasgow-haskell-users

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

Re: GHC and the Lazy Functional State Threads Paper
by Thomas Pasch 03 May '01

03 May '01

> So you can fix it for example by using a specialized version of > freezeArr inside accumArray, of type > (Ix i, IArray a e) => STArray s i e -> ST s (a i e) > This will give quite general type of accumArray: arbitrary immutable > array from the IArray class. freezeArr2:: (Ix i, IArray.IArray a e) => STArray s i e -> ST s (a i e) freezeArr2 = MArray.freeze > If the immutable array type used was particularly UArray, it would > be more efficient to use the corresponding STUArray instead of > STArray, so freezing could just copy a memory block (there are magic > specializations in ghc's libraries for such case). But if the element > type was to remain generic, the type would have to be constrained > over STUArray freezeArr3:: (Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e) => (MArray.STUArray s i e) -> ST s (a i e) freezeArr3 = MArray.freeze Is this the way to do it? I wonder a bit if this triggers the optimization if 'a' is of type STUArray. (By the way I still have problems to see where unboxed values are a good thing and were you should better avoid them.) In addition I wonder why there are so many array types. Are both STArray and IOArray really necessary and what's the difference between them? What about DiffArray? I'm still surprised by operations like 'unsafeFreezeArray' and 'freezeArray'. Shouldn't the garbage collector juge if there are still other references to a distinct object? Regards, Thomas

2 1

Linking vs. shared libs on Unix
by Thomas Pasch 02 May '01

02 May '01

Hello, In the windows version of ghc, there seems to be the possiblity to compile the libraries as shared 'dll's. Is the same possible for the unix version? The question is because I think the ghc executables are really blown up. A simple 'Hello, world' has 172 kBytes (358k unstripped) and the hello example of the GTK+ bindings is as big as 854 kBytes (2.2 MBytes unstripped), although it is link dynamically against: > ldd hello libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x40025000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40028000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40155000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4018a000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4018d000) libdl.so.2 => /lib/libdl.so.2 (0x401b1000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401b4000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401bc000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401cb000) libm.so.6 => /lib/libm.so.6 (0x402ae000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0x402cc000) libc.so.6 => /lib/libc.so.6 (0x402ed000) libpthread.so.0 => /lib/libpthread.so.0 (0x40400000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Best regards, Thomas

1 0