October 2005 - Glasgow-haskell-users

RE: Default name of target executable
by Simon Marlow 14 Oct '05

14 Oct '05

On 13 October 2005 18:57, Tomasz Zielonka wrote: > On 10/11/05, Tomasz Zielonka <tomasz.zielonka(a)gmail.com> wrote: >> On 10/11/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >>> Ok, let's close this bikeshed. Someone want to send us a patch? >> >> I will try to do this > > On which branch of GHC should I be working? > There are some differences between HEAD and STABLE > in the relevant areas. We always work on HEAD first, and port changes to STABLE if appropriate. Cheers, Simon

1 0

RE: Default name of target executable
by Simon Marlow 13 Oct '05

13 Oct '05

On 11 October 2005 11:04, Duncan Coutts wrote: > I'd tend to agree. > > It'd mean one less magic incantation to tell students when teaching > practicals (and one less thing for them to get wrong) if they can do: > > ghc --make Main.hs > > rather than > > ghc --make Main.hs -o Main > > (that's one advantage of ghci for teaching students, that 'ghci > Blah.hs' "Just Works"tm) Ok, let's close this bikeshed. Someone want to send us a patch? Cheers, Simon

2 2

RE: GHC-6.4.1 on FreeBSD-amd64 still not ported
by Simon Marlow 12 Oct '05

12 Oct '05

On 25 September 2005 18:54, Wilhelm B. Kloke wrote: > Though I have reported some sort of success on this in the last days, > I was too early. The ghc-inplace does not work on the target system. > It compiled because I have been too lax in following the instructions. > Here is the report, where the crossport fails on the i386host system: > > tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat > hc-files-to-go` > tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/StgStartup.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/StgStdThunks.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Updates.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Apply.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/Exception.hc: Cannot stat: No such file or > directory > tar: ghc-6.4.1/ghc/rts/HeapStackCheck.hc: Cannot stat: No such file > or directory > tar: ghc-6.4.1/ghc/rts/StgMiscClosures.hc: Cannot stat: No such file > or directory > tar: ghc-6.4.1/libraries/haskell-src/Language/Haskell/Parser.hs: > Cannot stat: No such file or directory > gmake: *** [hc-file-bundle] Fehler 1 > > bash-2.05b$ (cd ghc/rts; gmake PrimOps.o ) > ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static > -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h > -#include RtsUtils.h -#include StgRun.h -#include Schedule.h > -#include Printer.h -#include Sanity.h -#include STM.h -#include > Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h > -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h > -#include Apply.h -fvia-C -dcmm-lint -c PrimOps.cmm -o PrimOps.o > In file included from PrimOps.cmm:28: > /home/wb/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/includes/Cmm.h:288:2: > #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false > gmake: *** [PrimOps.o] Fehler 1 > > Similar messages for attemps to make other of the failing .hc files. > Perhaps crossporting from a 64bit system is easier. I presume that > once a working ghc is available, life is much easier, as Fedora > Linux-64 does not report problems. GHC is correctly generating the .hc file from the .cmm file, and then attempting to compile the .hc file using gcc. This latter step fails, as expected, because the .hc code is intended to be compiled on the target system. We just need to get those .hc files and take them to the target. Just doing 'make -k' in ghc/rts should leave all the .hc files behind, because you already have the -keep-hc-files flag in your command line, so GHC won't delete the intermediate .hc files even when the subsequent compilation stage fails. Cheers, Simon

2 1

Default name of target executable
by Tomasz Zielonka 12 Oct '05

12 Oct '05

Hello! When I work on a program which is going to be named LongProgramName, I usually put the Main module in file LongProgramName.hs. It would be nice if I could build it with --make like this: $ ghc --make LongProgramName instead of $ ghc --make LongProgramName -o LongProgramName Does anyone rely on the first one producing a.out? Because of this long syntax and comand-line completion I've even once lost the source code. I forgot to remove the .hs at the end of line: $ ghc --make Prog -o Prog.hs Best regards Tomasz

8 15

RE: How to make Data.Set.Set a Functor
by Simon Marlow 12 Oct '05

12 Oct '05

On 11 October 2005 17:16, Lajos Nagy wrote: > While working on a toy compiler I realized that Data.Set.Set (Set) is > not an instance of the Functor class. In other words: 'fmap' is not > defined on it. I tried various ways of defining an instance but I > failed. The reason is quite interesting: Set is a type constructor > (* -> *) so it should qualify it for being a Functor. (In a sense it > is very similar to a Map or a list.) However, most Set functions > require the elements of the Set to be an instance of Ord. The > problem is that this constraint cannot be deduced from the instance > declaration for Functor: > > instance Functor Data.Set.Set where > fmap f s = Data.Set.map f s A nice way to do this would be: data FSet a where FSet :: Ord a => Set a -> FSet a instance Functor FSet where ... if only GADTs worked with type classes :-) Cheers, Simon

1 0

RE: Default name of target executable
by Simon Marlow 11 Oct '05

11 Oct '05

On 10 October 2005 14:12, Wolfgang Jeltsch wrote: > Am Montag, 10. Oktober 2005 11:55 schrieb Niklas Broberg: >> [...] > >> Using a shell script is a possible work-around, but certainly not >> *the* solution. If there is no real reason for ghc to spit out a.out >> files, then surely choosing the exe name from the main input file >> would simplify a programmer's life. And for applications that >> desperately want a.out, well, there's still the -o flag, right? > > Maybe the makers of GHC wanted GHC to be "GCC compatible". There's no really deep reason for this choice, other than it being what GHC does normally - i.e. the default binary has always been a.out (main.exe on Windows) unless -o is given. I don't see enough of a compelling reason to change it, sorry. It's not broken, just slightly inconvenient. Cheers, Simon

3 2

RE: GADT question
by Simon Peyton-Jones 11 Oct '05

11 Oct '05

| > I plan to tackle it in the next couple of months. | | Would this also address how plain old Algebraic Data Types and type | classes work together? The issues seems related. Well that's specified by Haskell 98, so I don't want to change it. Instead, I propose to behave sensibly (i.e. uniformly) when a data type is declared using GADT-style syntax, but leave H98 unchanged. S

1 0

RE: Default name of target executable
by Simon Marlow 11 Oct '05

11 Oct '05

On 11 October 2005 06:29, Tomasz Zielonka wrote: > On 10/10/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> There's no really deep reason for this choice, other than it being >> what GHC does normally - i.e. the default binary has always been >> a.out (main.exe on Windows) unless -o is given. >> >> I don't see enough of a compelling reason to change it, sorry. It's >> not broken, just slightly inconvenient. > > It wasn't meant to be a bug report, only a feature request ;-) > > Actually, I was mostly interested if anyone would mind if GHC > chose the name based on the top-level module. > > Would you accept the patch? I'm slightly inclined not to make this change, but I could be swayed if there was enough interest in it. What I'm seeing so far is not overwhelming support for the change. Simon PJ is in favour, though. You can always use Cabal, BTW :) Anyone else? Cheers, Simon

5 4

RE: GADT question
by Simon Peyton-Jones 11 Oct '05

11 Oct '05

I'm afraid that GHC does not treat the interaction of type classes and GADTs properly. Your example shows this up even more starkly than usual: why should the IsZ thing work, but the Div one not work? The right fix is alas not very simple, which is why I have not done it. (It involves what Martin Sulzmann calls "implication constraints".) However, GADTs and type classes ought to be fine together, and the fact that many people have reported bugs suggests that the interaction is useful. I plan to tackle it in the next couple of months. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of J. Garrett Morris | Sent: 10 October 2005 18:06 | To: glasgow-haskell-users(a)haskell.org | Subject: GADT question | | Hello, | | I've been attempting to use GADTs to create a small domain specific | language, and I'm running into an odd problem. Adding one case to the | example at the beginning of the Wobbly types paper: | | data Term :: * -> * | where Lit :: a -> Term a | Inc :: Term Int -> Term Int | IsZ :: Num a => Term a -> Term Bool | Div :: Fractional a => Term a -> Term a -> Term a | If :: Term Bool -> Term a -> Term a -> Term a | | and extending the eval function accordingly: | | eval :: Term a -> a | eval (Lit i) = i | eval (Inc t) = eval t + 1 | eval (IsZ t) = eval t == 0 | eval (Div t u) = eval t / eval u | eval (If cond cons alt) = if eval cond then eval cons else eval alt | | I get an error "No instance for (Fractional a) arising from the use of | '/'" This seems odd to me, since Div is constrained to have | fractional arguments. Is there something obvious I'm missing?

2 1

RE: Default name of target executable
by Simon Marlow 11 Oct '05

11 Oct '05

On 11 October 2005 10:04, Christian Maeder wrote: > Simon Marlow wrote: >> You can always use Cabal, BTW :) > > ghc should supply it, too. GHC does come with Cabal. ? Cheers, Simon

1 0