- Glasgow-haskell-users

HTk for ghc-5.04.2
by George Russell 23 Jan '03

23 Jan '03

I've compiled HTk for ghc-5.04.2 on Solaris, Linux and Windows, and put binary bundles at http://www.informatik.uni-bremen.de/htk/ So you can write portable graphical user interfaces using the latest release of your favorite Haskell compiler. Sorry it's a bit late; it's not that it's difficult, it's just that I am a shortage of manpower. I hope I produce binaries for ghc-5.04.3 a bit faster.

1 0

RE: Ambiguous type variable
by Simon Peyton-Jones 23 Jan '03

23 Jan '03

I've been working on improving this error message. Here's the current version: R.hs:1: Ambiguous type variable `a' in constraints `Random a' arising from use of `randomRs' at R.hs:4 `Num a' arising from the literal `0' at R.hs:4 Possible cause: the monomorphism restriction applied to the following: f :: Int -> [a] (bound at R.hs:4) better, eh? | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 22 January 2003 18:28 | To: GHC Users Mailing List | Subject: Ambiguous type variable | | Hi all, | | This works fine, as expected | > f :: (Num a, Random a) => Int -> [a] | > f = randomRs (0,1).mkStdGen | | If I skip the type signature, though, I get the following error messages: | Main.hs:14: | Ambiguous type variable(s) `a' in the constraint `Random a' | arising from use of `randomRs' at Main.hs:14 | In the first argument of `(.)', namely `randomRs (0, 1)' | In the definition of `f': (randomRs (0, 1)) . mkStdGen | | Main.hs:14: | Ambiguous type variable(s) `a' in the constraint `Num a' | arising from the literal `1' at Main.hs:14 | In the first argument of `randomRs', namely `(0, 1)' | In the first argument of `(.)', namely `randomRs (0, 1)' | | Why exctly can't ghci figure how the type of f? | | This just happens when loading the code from a file, | > :t randomRs (0,1).mkStdGen | in ghci works fine. | | J.A. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Ambiguous type variable
by Jorge Adriano 22 Jan '03

22 Jan '03

Hi all, This works fine, as expected > f :: (Num a, Random a) => Int -> [a] > f = randomRs (0,1).mkStdGen If I skip the type signature, though, I get the following error messages: Main.hs:14: Ambiguous type variable(s) `a' in the constraint `Random a' arising from use of `randomRs' at Main.hs:14 In the first argument of `(.)', namely `randomRs (0, 1)' In the definition of `f': (randomRs (0, 1)) . mkStdGen Main.hs:14: Ambiguous type variable(s) `a' in the constraint `Num a' arising from the literal `1' at Main.hs:14 In the first argument of `randomRs', namely `(0, 1)' In the first argument of `(.)', namely `randomRs (0, 1)' Why exctly can't ghci figure how the type of f? This just happens when loading the code from a file, > :t randomRs (0,1).mkStdGen in ghci works fine. J.A.

2 2

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