October 2002 - Glasgow-haskell-users

RE: ghc --make -odir x -hidir x chooses strange location for x
by Simon Marlow 24 Oct '02

24 Oct '02

> >Which static options in particular do you need to change? > > Just the usual suspects: -package mostly for me, the occasional > -O for sources from folks who have figured out which of their many > files really need/profit from optimisation. I'd argue that -package is a global option and should stay that way. The only reason you might want to disable -package for certain modules and not others is if you want to do some tricks with module shadowing - and this definitely isn't supported in GHC. You should pass the same -package to every compilation. The optimisation options are a different matter. I agree, they really should be dynamic. > Was interesting to look at the list again, though - in my memory, > the list of static flags was longer than it actually turns out to be. > -package seems to be the only one left that really hurts.. > > Well, and the lower level equivalents, of course: -i, -l, -L (these > would be especially useful in combination with ghci: just have > everything in one file, pass it to ghci and get going..). Arguably -I should be dynamic, but I don't think it does much harm being static. I think -i is a global option in the same sense as -package, though. The library options -l and -L don't really matter, since they're only used at link time and you wouldn't want to put them in OPTIONS anyhow. Cheers, Simon

1 0

RE: ghc --make -odir x -hidir x chooses strange location for x
by Simon Marlow 24 Oct '02

24 Oct '02

> I'd have expected -odir/-hidir to put files in directories relative > to the source directories. Is that an unreasonable expectation? No, it's not an unreasonable expectation, and in fact I've made that change in CVS. However the changes are too large to backport to 5.04.2, I'm afraid. > 2) with static options not accepted in source file pragmas, I > often end up compiling everything with the superset of options. > > Shouldn't it be possible to fork a new copy of ghc with new > static options for parts of a ghc --make run? Which static options in particular do you need to change? > 3) shouldn't there be a way of telling ghc --make about ways > to generate the .hs/.lhs files it is looking for (aka suffix rules)? > > The standard examples are happy, cpp, drift, .. As Malcolm suggested, use hmake, or a Makefile (and suffer slower compile times, I'm afraid). I don't think we intend to implement this in GHC. Cheers, Simon

3 2

ghc --make -odir x -hidir x chooses strange location for x
by Claus Reinke 23 Oct '02

23 Oct '02

I'm a great fan of ghc --make, but there seem to be a few features that could be improved: 1) -odir x (same for -hidir) seems to put all object files into a directory x relative to the call to ghc.. Well, I wanted .o files out of the way, but not that far out of the way! Not only do all .o files for the source file hierarchy end up in one directory, that directory has no relation to the source file location. So, even if I don't get name conflicts in that one directory, as soon as I reuse part of my source directories for a second project, that'll end up compiling its own copies of the .o files. Unless I put all .o files for all my projects in the same directory.. I'd have expected -odir/-hidir to put files in directories relative to the source directories. Is that an unreasonable expectation? 2) with static options not accepted in source file pragmas, I often end up compiling everything with the superset of options. Shouldn't it be possible to fork a new copy of ghc with new static options for parts of a ghc --make run? 3) shouldn't there be a way of telling ghc --make about ways to generate the .hs/.lhs files it is looking for (aka suffix rules)? The standard examples are happy, cpp, drift, .. Just a few suggestions, Claus -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/

2 2

Problem with ghc-5-04-1.msi
by David Sabel 23 Oct '02

23 Oct '02

While installing the file the following error occurs: Invalid Drive c:\ after that error message the "GHC setup ended prematurely because of an error" My Computer doesn't have a drive c:\, the windows partition is on d:\. The previous .msi-Version (5.04) didn't have this error. David

2 2

Publications from Chipworks
by Chipworks＠haskell.org 23 Oct '02

23 Oct '02

1 0

RE: deriving weirdness on newtypes
by Simon Peyton-Jones 22 Oct '02

22 Oct '02

Hal I have fixed this bug in the HEAD. The fix is more than a tiny one, so I'm inclined to leave it as a know bug in 5.02.2. It'd cost me another few hours to patch it into the 5.02 branch. I don't think this is a widely-used feature, yet. Even John Hughes didn't notice the bug. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 02 October 2002 18:58 | To: GHC Users Mailing List | Subject: deriving weirdness on newtypes | | So I love the fact that I can derive anything I want on | newtypes. However, there seem to be problems with it. If I write: | | newtype Foo = Foo Int deriving (Show) | x = show (Foo 5) | | Then x is "Foo 5" | | However, if I do | | newtype Foo = Foo Int deriving (Num) | x = show (Foo 5) | | Then the definition of 'x' claims that there is no Show instance of Foo. | | However (this is where it gets weird). If I do: | | newtype Foo = Foo Int deriving (Num) | x = show ((Foo 5) + 4) | | then x is *valid* and has value "9", not "Foo 9". Moreoever, I can even | do: | | x = show ((5::Foo) + 4) | | and this x has value "9". | | Futhermore, if I do: | | newtype Foo = Foo Int deriving (Show,Num) | | then "show (Foo 5)" has value "5", not "Foo 5". | | IMO, the correct value of "show (Foo 5)" no matter which of the above we | have is "Foo 5". I think the deriving mechanism should be changed in two | ways. | | (1) If you derive X on a newtype and X is a subclass of Y, | you must have an instance of Y on that newtype. This is | how it works on data types, and I think makes sense. | For instance, | newtype Foo = Foo Int deriving (Ord) | should be just as illegal as | data Foo = Foo Int deriving (Ord) | | (2) The derived Show instances for newtypes in the presense of | derived Num instances should be fixed so that the | constructor is also printed. Rational: adding something | to the list of derived classes should *not* change | previously derived instances. | | There is yet another thing. If we have: | | newtype Foo = Foo Int deriving (Num) | instance Show Foo where { show = undefined } | | then, the value of 'show (Foo 5)' is undefined, but the value of 'show | (5::Foo)' is "5". definately *WRONG*. | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: more undecidable instances, but why
by Simon Peyton-Jones 22 Oct '02

22 Oct '02

| instance MArray IOUArray a IO => MArray IOUArray (S a) IO where | However, GHC complains: | | /nfs/isd/hdaume/projects/MESumm/Linear2/Linear2.hs:76: | Non-type variables in constraint: MArray IOUArray a IO | (Use -fallow-undecidable-instances to permit this) | But I don't see why this is undecidable. As I understand it, undecidable | instances basically arise when context reduction might not | terminate. Here, it always will (AFAICS). In this case it's not undecideable, but GHC isn't clever enough to spot that. The point is that that each of the types on the left of the => are smaller than the types on the right MArray IOUArray a IO Is smaller than MArray IOUArray (S a) IO But GHC isn't clever enough to spot that. In general it's the halting problem. Doubtless there are useful special cases. Simon

1 0

Sesso ma vero...
by Giada 22 Oct '02

22 Oct '02

IL MIGLIOR PORTALE PER ADULTI http://www.grandifighe.fra.bz FILMATI, FOTO, VIDEO-ANNUNCI, WEB-CAM con ragazze che potrebbero benissimo essere le tue vicine di casa... CHATTA con le ragazze della rete pi� provocanti http://www.grandifighe.fra.bz il sito contiene materiale erotico esplicito VIETATISSIMO minori 18 anni per cancellarti dalla news letter scrivi a writeln(a)virgilio.it writeln(a)ciaoweb.it

1 0

FFI : A failing example
by Francis Girard 22 Oct '02

22 Oct '02

Hello, I'm a beginner trying to use FFI. I copied the example given in : The Glasgow Haskell Compiler User's Guide, Version 5.04 Chapter 8. Foreign function interface (FFI) -------------------------------------------------------------------------- module Foo where foreign export ccall foo :: Int -> IO Int foo :: Int -> IO Int foo n = return (length (f n)) f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) -------------------------------------------------------------------------- Copied it verbatim. And simply tried to compile it using "ghc -c Foo.hs -o Foo.o" and always got the error : Type signature given for an expression (at the line following the "foreign export") I then tried to import the "Foreign" and "Foreign.C" modules but it didn't change anything. I am missing something and I would be VERY grateful to anyone that tells me what. Thank you Francis Girard Le Conquet (France) Francis.Girard(a)free.fr

2 1

RE: Optimisation
by Simon Marlow 21 Oct '02

21 Oct '02

> What's the standard paper about optimisations and program > transformation? A recent one is "Secrets of the GHC inliner", available here: http://www.research.microsoft.com/~simonpj/Papers/inlining/index.htm The other good place to look is Andre Santos's thesis (sorry, I don't have a URL for that handy). > Which transformations are used by the GHC, especially which > optimisations are applied at optimisation level 0, 1 and 2? The only transformation which is currently applied at level 2 but not level 1 is constructor specialisation (it is experimental and we haven't measured the benefit yet). Level 1 has everything else turned on, and level 0 has simplification only. Cheers, Simon

1 0