- Glasgow-haskell-users

RE: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
by Simon Marlow 10 Sep '03

10 Sep '03

[ moved to ghc-users ] > On Wednesday 10 September 2003 07:22 am, Hal Daume III wrote: > > I agree with Malcolm, with the possible addition of: > > > > keep -fglasgow-exts as it is (or, even, perhaps continue > making it the > > "add all extensions keyword). also have -fffi, -farrows, -fth, etc. > > but also have, -fnoth and -fnoffi. that way, if a lot of > us have code > > that uses all the extensions other than TH and have lots of > code that > > looks like (foo$bar), we can just to -fglasgow-exts -fnoth. > > > > seems to be a win-win. > > I agree; I want a catch-all flag, but I also want to > flexibility to be able > to pick and choose. Both -f<feature> and -fno<feature> is > the way to go IMHO. Ok, I've added -fth and -fimplicit-params (and the appropriate -fno- forms). The -fglasgow-exts flag will continue to imply these for the time being, so nothing should break. Cheers, Simon

1 0

RE: stg_ap_v_ret porting crash: solved?
by Simon Marlow 10 Sep '03

10 Sep '03

> $ uname -msr > OpenBSD 3.3 sparc > > $ cat > test.hs > import System.Info > main = print System.Info.arch >> print System.Info.os > > $ > /usr/obj/ports/ghc-6.0.1/ghc-6.0.1/ghc/compiler/ghc-inplace test.hs > > $ ./a.out > "sparc" > "openbsd" Congrats :-) Would you like to add this port to the relevant section of the Building Guide? Cheers, Simon

1 0

RE: GHC build fails without alex
by Simon Marlow 09 Sep '03

09 Sep '03

> When building the current version of GHC from CVS without having alex > installed, the build tries to use "alex-inplace" instead, but > apparently the dependency that tells make(1) to build that executable > before using it is missing. I had to execute > > make ProjectsThatExist=alex > > in the top level before the build of GHC itself would succeed. I > guess, this qualifies as a bug. :-) It's not really a bug (well, the same situation arises with Happy and Haddock). There are no dependencies between top-level projects. I'll switch the default build order so that these packages get build before GHC if you say 'make' at the top level. Cheers, Simon

3 2

RE: GHC build fails without alex
by Simon Marlow 09 Sep '03

09 Sep '03

> | typecheck/TcSimplify.lhs:22: > | Module `TcUnify' (hi-boot interface) does not export > `unifyTauTy' > | make[1]: *** [stage2/typecheck/TcSimplify.o] Error 1 > | make[1]: Leaving directory > `/usr/local/src/ghc-current/ghc/compiler' > | make: *** [stage2] Error 2 This is now fixed. BTW, cvs-ghc(a)haskell.org is a better place for bug reports related to the CVS version of GHC. Cheers, Simon

1 0

Query regarding GHC handling of overlapping instances.
by Keean Schupke 09 Sep '03

09 Sep '03

I have been doing some work recently which involves classes with overlapping instances... for example class Test x y where test :: x -> y instance Test (a b) (c b) where test = instance Test (a b) (a b) where test = This gives an overlapping instance error - which cannot be avoided with -fallow-overlapping-instances. However - it is fairly obvious that the first case 'a' cannot be unified with 'c' or it would be a type error, therefore the cases do not overlap... Is this a bug in ghc, is it easily fixable - or am I confused? This leads on to my second point: A request for a new feature (if it cannot be done with existing features). I would like to be able to specify class non-membership. Say we have orthogonal classes A and B, I can see situations where definitions like the following would be useful: instance (A a,B a) => C a ... instance (A a, (not B) a) => C a ... perhaps the complete set of boolean operators would make sense for completeness allowing: instance ((A a) and ((B a) or (C a))) => D a ... Obviously functions defined in classes B and C would not be usable in the function definitions of D because we are uncertain of membership of B and C individually. Regards, Keean Schupke.

1 0

GHC build fails without alex
by Peter Simons 08 Sep '03

08 Sep '03

When building the current version of GHC from CVS without having alex installed, the build tries to use "alex-inplace" instead, but apparently the dependency that tells make(1) to build that executable before using it is missing. I had to execute make ProjectsThatExist=alex in the top level before the build of GHC itself would succeed. I guess, this qualifies as a bug. :-) Peter

1 0

RE: Porting GHC to powerpc-unknown-linux
by Simon Marlow 08 Sep '03

08 Sep '03

> I was a bit too soon reporting the sparc-sun-solaris2, two > attempts have died with stg_ap_v_ret. Same result sparc-*-openbsd. > > Here's an updated list: > > +-----------------+--------------------+---------------------------+ > | HOST | TARGET | Unregisterised bootstrap | > +-----------------+--------------------+---------------------------+ > | i386-*-openbsd | i386-*-openbsd | YES | > | | i386-*-freebsd | YES | > | | i386-*-linux | YES | > | | i386-*-solaris2 | YES | > | | | | > | | sparc-sun-solaris2 | stg_ap_v_ret | > | | sparc-sun-openbsd | stg_ap_v_ret | > | | | | > | | m68k-apple-netbsd | boots libs, dies in gmp | > | | | | > | | alpha-dec-osf3 | in progress | > +-----------------+--------------------+---------------------------+ > > Is there an endianess thing here? What is the endianess of the > amd64 and the powerpc? Are than any tricks I can try? Hmm. I'm still wondering if AutoApply.hc is somehow wrong - has this file been re-generated on the target machine? It should have been shipped with the HC files from the host machine. Do you have GhcUnregisterised=YES in build.mk on the target machine for these builds? Does it help if you add it and start the build from scratch on the target machine? Cheers, Simon

3 2

Raylı Dolap Sistemleri
by raydoor 08 Sep '03

08 Sep '03

1 0

RE: Porting GHC to powerpc-unknown-linux
by Simon Marlow 05 Sep '03

05 Sep '03

> simonmar: > > There's a small possibility that I've missed something out from the > > instructions, I suppose :) > > No. They are perfect. I've stress tested them today :p > > +-----------------+--------------------+----------------------------+ > | HOST | TARGET | Unregisterised bootstrap | > +-----------------+--------------------+----------------------------+ > | i386-*-openbsd | i386-*-openbsd | YES | > | | i386-*-freebsd | YES | > | | i386-*-linux | YES | > | | i386-*-solaris2 | YES | > | | sparc-sun-solaris2 | YES | > | | sparc-sun-openbsd | in-progress | > | | m68k-apple-netbsd | in-progress | > | | | | > | | alpha-dec-osf3 | dies on host with: | > | | | cc1: Invalid option `ieee' | > +-----------------+--------------------+----------------------------+ > > So all 32-bit platforms have worked or are looking good, but > the 64 bit couldn't get of the host machine. The problem you experienced on the Alpha has a perfectly rational explanation. The .hc files we generate on the host machine are designed to be compiled on the target machine only; it's entirely possible that the configuration of the compiler on the host machine may not be able to compile these .hc files to .o. Ideally, the build system should know when it is cross-compiling .hc files and just generate .hc files (passing -C to GHC instead of -c -keep-hc-files). I thought about doing this, but quickly realised it would be a lot of work to get right. You might be able to hack around it with lots of 'make -k' on the host machine. > But I think we can see that GHC is portable now :) That's what I like to hear :-) Cheers, Simon

4 6

RE: bracket, (un)block and MonadIO
by Simon Marlow 04 Sep '03

04 Sep '03

> However, the definition of bracket relies on block and > unblock, which have the > following types: > > bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c > > block :: IO a -> IO a > > unblock :: IO a -> IO a > > This forces f to be an IO action in the above withQuery > function. If bracket, > block, and unblock had these types, my helper function would > be well typed: > > > bracket :: MonadIO m => m a -> (a -> m b) -> (a -> m c) -> m c > > block :: MonadIO m => m a -> m a > > unblock :: MonadIO m => m a -> m a > > Would anything prevent block, unblock, bracket (and other > similar functions > working on IO actions) from being generalized to all intances > of MonadIO? I'm afraid I can't see a way to generalise the types of block and unblock, since they are based on underlying primitives that really do have type (IO a -> IO a). Perhaps if your monad is isomorphic to IO, it could be done, but otherwise I don't think it's possible. Unless I'm missing something. Cheers, Simon

3 2