January 2003 - Glasgow-haskell-users

MonadPlus IO
by Dean Herington 22 Jan '03

22 Jan '03

According to the Haddock documentation for Control.Monad at http://www.haskell.org/ghc/, `IO` is an instance of `MonadPlus`. 1. Where in documentation is this instance described? 2. Where in source code is this instance implemented? 3. Could links to the answers to 1 and 2 be added to the Haddock documentation for Control.Monad? Obviously, these questions apply more generally than just to `MonadPlus IO`. Dean

2 1

Invalid option combination
by Rafael Martínez Torres 22 Jan '03

22 Jan '03

what may be wrong here ? ghc -ldl -fglasgow-exts -cpp -Iinclude -funbox-strict-fields -package-name base -O -H24m -keep-hc-files-too -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregisterised -fvia-C -split-objs -c GHC/Base.lhs -o GHC/Base.o ghc-5.04.2: invalid option combination Usage: For basic information, try the `--help' option.

1 1

RE: Invalid option combination
by Simon Marlow 22 Jan '03

22 Jan '03

You can't use -split-objs with -fno-asm-mangling (boring reason: the mangler is required to generate some annotations which are consumed by the splitting script). Cheers, Simon > -split-objs doesn't seem to match among the "unregisterised" flags > (-fno-asm-mangling, -funregisterised, -optc-DUSE_MINIINTERPRETER...) > > On Wed, 22 Jan 2003, Rafael Martínez Torres wrote: > > > what may be wrong here ? > > > > ghc -ldl -fglasgow-exts -cpp -Iinclude > -funbox-strict-fields -package-name base -O -H24m > -keep-hc-files-too -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER > -fno-asm-mangling -funregisterised -fvia-C -split-objs -c > GHC/Base.lhs -o GHC/Base.o > > ghc-5.04.2: invalid option combination > > Usage: For basic information, try the `--help' option. > > > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

PROPS
by Gast 21 Jan '03

21 Jan '03

WE HAVE FOR SALE: 1 500 PROPS GALAVANIZED SIZE 260-350, 500 sqm DOKA FRAMAX ALU and STEEL. PICTURES AND MORE INFO CAN WE PROVIDE YOU PER E-MAIL. BEST REGARDS. STABILO.

1 0

RE: Avoiding "No explicit method ..." warnings
by Simon Peyton-Jones 21 Jan '03

21 Jan '03

| This seems to be a lot of mechanism for questionable benefit. A simpler and cleaner | approach, IMHO, is the following: I rather agree. One other idea though. Suppose you say class ComplicatedClass x where _simpleTitleFn :: x -> String muchMoreComplicatedTitleFn :: extra arguments -> x -> IO ... In general GHC doesn't report "warning unused" for variables whose name begin with an underscore. In the case of class methods, I don't think it suppresses the warning, but that would be an easy change to make. Indeed, it would arguably be more consistent to do so anyway > #-}) which compiles exactly as normal except that (1) no warning is > given for instances which don't define it; (2) a warning is given > whenever anyone outside the class declaration *uses* simpleTitleFn. The "_" idea would achieve (1). You could get (2) by not exporting the "_" method from the module defining ComplicatedClasss. How would that be? Simon

2 1

Avoiding "No explicit method ..." warnings
by George Russell 21 Jan '03

21 Jan '03

This isn't a bug, just a suggestion. It's not even a very important suggestion, but one that might be worth implementing if it's easy and you can find the the time. Or perhaps I am just doing things the wrong way? The point is that I sometimes have something like the following situation class ComplicatedClass x where simpleTitleFn :: x -> String muchMoreComplicatedTitleFn :: extra arguments -> x -> IO (WithError (Source blah blah blah String) muchMoreComplicatedTitleFn _ x = [ ... some expression involving simpleTitleFn ...] The idea is that only muchMoreComplicatedTitleFn must always work; however instances may choose to implement it directly, or implement the much simpler function simpleTitleFn (if that does all they want). At the moment the situation is that someone who defines just "muchMoreComplicatedTitleFn" will get an unnecessary warning message from the compiler about "No explicit method or default method for simpleTitleFn". I suggest instead introducing a new class of optional method (for example, via a pragma {-# OPTIONAL_METHOD simpleTitleFn #-}) which compiles exactly as normal except that (1) no warning is given for instances which don't define it; (2) a warning is given whenever anyone outside the class declaration *uses* simpleTitleFn.

3 2

RE: Using --make with -odir and hierarchical modules
by Simon Marlow 20 Jan '03

20 Jan '03

> Martin Norbäck <d95mback(a)dtek.chalmers.se> writes: > > > The GHC manual needs to specify what happens when you use -odir and > > hierarchical modules with --make. > > It may be of interest to note that hmake currently uses > solution 2 below. > > > Solution 2: files put in -odir are put in directories > (files will end up > > in Program/output/Bar/Module.o and Program/output/Foo/Module.o) > > This is also a slight change in semantics, since files are put in > > directories. May affect Makefiles that does "ar output/*.o" > or similar. And this is also what the current CVS version of GHC does. Note that you need to create the directories if they don't exist (GHC won't do it for you). Please also see http://www.haskell.org/pipermail/glasgow-haskell-users/2002-December/004569…, which contains a specification of GHC's current search strategy. Cheers, Simon

2 1

RE: broken link
by Simon Marlow 20 Jan '03

20 Jan '03

> The page > <http://haskell.cs.yale.edu/ghc/docs/5.04.2/html/network/index.html> > links to the "CGI" library, but following that link produces the > following error: > > Forbidden > > You don't have permission to access > /ghc/docs/5.04.2/html/network/Network.CGI.html on this server. > > Looking at the download-able archive of the documentation, it appears > that the page is simply missing. The page is there, but I assume because it contains the string ".CGI" the server is mistakenly refusing to serve it. I'll see if the webmaster knows why. > On a similar notion: The "parent" link in the generated documentation > almost never works. Say, you are on the documentation for > Control.Arrow and follow the "parent" link, then the link will point > to "PATH/Control.html" -- which does not exist; the correct name would > be "PATH/index.html". I _guess_ that this can be fixed by providing > appropriate flags to Haddock, but I am not sure. Yes, this should be fixed. The idea is to take you to the parent *module*, which for many nodes in the tree doesn't exist (eg. Foreign.C has a parent, but Control.Monad doesn't). The parent button should just be removed if there isn't a parent module. Cheers, Simon

1 0

RE: comparison of execution speed of array types
by Zdenek Dvorak 20 Jan '03

20 Jan '03

Hello, >DiffArray seems to be broken :). Either that or I'm using it >incorrectly. I've attached the relevant code, but when I don't reverse >the array everything works fine; when I reverse it the program doesn't >(seem to) halt. I've tried to use DiffArray recently and it is terribly slow. I was forced to write my own version (it is a bit faster, but still nothing great). My suspicion about the result of your measuring is that it does the updates in reversing the array one by one, thus leading to quadratic behavior. Zdenek Dvorak _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

Using --make with -odir and hierarchical modules
by Martin Norbäck 20 Jan '03

20 Jan '03

The GHC manual needs to specify what happens when you use -odir and hierarchical modules with --make. I posted to the list about this before but it was not resolved: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-October/004178.… Here is an example: . |-- Library | |-- Bar | | `-- Module.hs | `-- Foo | `-- Module.hs `-- Program |-- Program.hs `-- output Program.hs uses Bar.Module and Foo.Module. Then, doing cd to Program # ghc -i../Library --make Program ghc-5.04.2: chasing modules from: Program Compiling Bar.Module ( ../Library/Bar/Module.hs, ../Library/Bar/Module.o ) Compiling Foo.Module ( ../Library/Foo/Module.hs, ../Library/Foo/Module.o ) Compiling Main ( Program.hs, ./Program.o ) ghc: linking ... everything works fine. Using -odir: # ghc -i../Library -odir output --make Program ghc-5.04.2: chasing modules from: Program Compiling Bar.Module ( ../Library/Bar/Module.hs, output/Module.o ) Compiling Foo.Module ( ../Library/Foo/Module.hs, output/Module.o ) Compiling Main ( Program.hs, output/Program.o ) ghc: linking ... <LONG LINKER ERROR> Error, since both modules are compiled to the same file. This should not happen. What should be done about it? Solution 1: -odir is relative to the source directory (files will end up in Library/Bar/output/Module.o and Library/Foo/output/Module.o). This is a change of semantics from the earlier behaviour of -odir (files are put in another place). On the other hand, it may be more natural to put files relative to their source, like --make without -odir does. The question remains what to do if -odir is an absolute path. Solution 2: files put in -odir are put in directories (files will end up in Program/output/Bar/Module.o and Program/output/Foo/Module.o) This is also a slight change in semantics, since files are put in directories. May affect Makefiles that does "ar output/*.o" or similar. Solution 3: files put in -odir will have their full module name (files will end up in Program/Output/Bar.Module.o and Program/Output/Foo.Module.o) This is an ever lesser change in semantics, and is better than solution 2 in my opinion. I would recommend using solution 1 if the path name is relative and solution 3 if it's absolute. Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

5 4