- Glasgow-haskell-users

GHC source code improvement ideas
by Twan van Laarhoven 09 Jan '08

09 Jan '08

Hello GHC people, I was trying my hand at some GHC hacking, and I couldn't help but notice that much of the code looks (IMHO) horrible. There are some things that look as if they haven't been touched since the Haskell 1.3 days. The most striking is the use of `thenXX` instead of do notation. I was thinking of cleaning up some of this. In particular: 1a. Use do notation where possible instead of `thenXX`. 1b. Even better, use Applicative where possible. For example ds_type (HsFunTy ty1 ty2) = dsHsType ty1 `thenM` \ tau_ty1 -> dsHsType ty2 `thenM` \ tau_ty2 -> returnM (mkFunTy tau_ty1 tau_ty2) Could be rewritten as ds_type (HsFunTy ty1 ty2) = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2 2. Investigate the need for all these mappM functions. To quote the source: "Standard combinators, but specialised for this monad (for efficiency)". Wouldn't a SPECIALIZE pragma work just as well? 3. In general, use standard functions when they are available. Currently GHC has its own sort function and its own versions of FiniteMap/Data.Map and Text.PrettyPrint. Using standard functions/data structures will a) make GHC smaller and therefore easier to maintain, and b) will make the code easier to understand for someone who knows the standard library. 4. A more radical change would be introducing hierarchical modules. This could be just a matter of renaming the directories to start with an upper case character and changing the import declarations. This gives module names like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the GHC api. How do the GHC developers feel about this? Would such paches be gladly excepted? Or will they be directly forwarded to the bit bucket? Twan

11 13

problem with GHC installaion on x86_64
by Yu Di 09 Jan '08

09 Jan '08

Hi, I am trying to use ghc on a 64-bit machine (uname -a shows: Linux ... 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux), I first downloaded the x86 binary bz2 file and successfully installed it, but when I use that version to compile my programs, I get a lot of error messages like: /tmp/ghc2448_0/ghc2448_0.s:10214:0: Error: suffix or operands invalid for `push' Then I downloaded the x86_64 binary bz2 file and tried to install it, but when I am running "configure --prefix=...", I got: pwd: timer_create: Invalid argument and configure fails. So where should I be able to get a working version for this machine? Thanks! Di, Yu 1.8 ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

2 1

Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
by Thorkil Naur 08 Jan '08

08 Jan '08

Hello, On Friday 04 January 2008 12:03, Christian Maeder wrote: > ... Thanks a lot for this response. > I'm not happy about this framework hick-hack either. I am glad we agree about that. > I've only pushed > it, because we needed a readline solution on macs. I understand that there are problems in this area, but I am not convinced that they could not be solved without the renamed and/or modified readline library. I am sorry if you have done that already elsewhere, but I don't recall having seen any details about your difficulties. Would you be kind enough to supply some details? Thanks a lot. > The alternative is to use static linking of gmp (as suggested by chak) > _and_ readline (version 5), so that user programs are also statically > linked with these libs. Again, I am not convinced that this is the only alternative. > ... > Regarding this actual GNUreadline-framework.zip replacement, this is > harmless and seems to matter only for those who build ghc with > frameworks (as only the inclusion of header files changed) It is perhaps without any practical consequences, but I have seen many cases where circumstances managed to create the most glorious confusion out of the most innocently looking changes. So I would maintain that replacing something that you have published with something different is not a good idea. > > In any case we should strive to fix the frameworks issues _and_ add > support for static linking of gmp, readline and possibly other libs > (plus license issues). I fully agree with this. Ideally, the plan would be to, first, figure out what the ideal solution looks like. And then work towards that ideal solution. Making sure that what we introduce on the way as short-term hacks are clearly marked as such, to ensure that they don't impress themselves on people's minds as part of the final solution. I have every intention to work out some ideal (or perhaps more modestly: better) solution. But whether it will emerge in time to make any difference, remains to be seen. > > HTH Christian Thanks and best regards Thorkil

5 6

GHC Core question
by Neil Mitchell 08 Jan '08

08 Jan '08

Hi I've compiled the Debug.Trace module to Core, but can't understand the resulting output. The original code is: trace string expr = unsafePerformIO $ do putTraceMsg string return expr The core is: Debug.Trace.trace = \ (@ a) -> __letrec { trace :: GHC.Base.String -> a -> a [] trace = \ (string :: GHC.Base.String) (expr :: a) -> GHC.Base.$ @ (GHC.IOBase.IO a) @ a (GHC.IOBase.unsafePerformIO @ a) (>> @ () @ a (Debug.Trace.putTraceMsg string) (return @ a expr)); $dMonad :: GHC.Base.Monad GHC.IOBase.IO [] $dMonad = $dMonad; return :: forall a. a -> GHC.IOBase.IO a [] return = GHC.Base.return @ GHC.IOBase.IO $dMonad; $dMonad :: GHC.Base.Monad GHC.IOBase.IO [] $dMonad = GHC.IOBase.$f16; >> :: forall a b. GHC.IOBase.IO a -> GHC.IOBase.IO b -> GHC.IOBase.IO b [] >> = GHC.Base.>> @ GHC.IOBase.IO $dMonad; } in trace; And my Haskell reformatting of that is: Debug.Trace.trace = let trace string expr = unsafePerformIO $ putTraceMsg string >> return expr $dMonad = $dMonad; return = GHC.Base.return $dMonad; $dMonad = GHC.IOBase.$f16; >> = GHC.Base.>> $dMonad; in trace However, that let expression has two bindings for $dMonad, one of which looks like a black-hole. Are the semantics of __letrec different from let in some way? Thanks Neil

3 5

wish for more-usable bindist
by Isaac Dupree 08 Jan '08

08 Jan '08

the i386 linux ghc bindist still uses readline 4 <http://haskell.org/ghc/download_ghc_682.html>, which is hard to get: readline 5.0 came out almost three and a half years ago <ftp://ftp.cwru.edu/pub/bash/> And I don't want to pollute my Ubuntu system with "compatibility RPMs"; in fact I intend to install the bindist as my local user so I don't pollute it with extra GHCs either, except I can't. Could there be a bindist with modern readline, or perhaps is it possible to statically link with readline? ~Isaac

6 7

reifying is-a relation
by Jorge Marques Pelizzoni 07 Jan '08

07 Jan '08

Hi, all! I guess what I am about to ask is currently impossible, but as you haskellers always manage to amaze me and there is plenty of new features in GHC I am not familiar with here it goes. Given two type classes A t and B t, I'd like to derive different A t instances depending exactly on whether t is an instance of B. In other words, is it possible to define a class (actually a type-level function) IsB t f such that: IsB t HTrue <=> (B t) exists IsB t HFalse <=> otherwise? If not, is this wish intrisically pointless? Thanks in advance. Cheers, Jorge M. Pelizzoni ICMC - Universidade de São Paulo

1 0

Rank-2 polymorphism and pattern matching
by Jim Apple 07 Jan '08

07 Jan '08

The following won't compile for me isnull :: (forall a . [a]) -> Bool isnull ([] :: forall b . [b]) = True Couldn't match expected type `forall b. [b]' against inferred type `[a]' In the pattern: [] Wrapping it in a constructor doesn't help, though I can define a "null": data NullList = NullList (forall a . [a]) null = NullList [] isnull2 :: NullList -> Bool isnull2 (NullList []) = True Why? Jim

3 5

Re: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2]
by Christian Maeder 07 Jan '08

07 Jan '08

Hi Emmanuel, sqlite3 must be installed on your mac, i.e. a file "libsqlite3.dylib". (I don't have it, too.) If it is say under /opt/local/lib you may need to pass "-optl-L/opt/local/lib" to ghc's command line (or set LD_LIBRARY_PATH) HTH Christian manu wrote: > Macintosh:blog_old_with_sqlite3 manu$ ghc --make newArticle.hs -o > new_article.c > gi > [3 of 3] Compiling Main ( newArticle.hs, newArticle.o ) > Linking new_article.cgi ... > ld: atom sorting error for > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in > /usr/local/lib/HDBC-sqlite3-1.1.3.0/ghc-6.8.2/libHSHDBC-sqlite3-1.1.3.0.a(Types.o) > > ld: atom sorting error for > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl and > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CStmt_closure_tbl in > /usr/local/lib/HDBC-sqlite3-1.1.3.0/ghc-6.8.2/libHSHDBC-sqlite3-1.1.3.0.a(Types.o) > > Undefined symbols: > "_sqlite3_errmsg", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziUtils_zdwccall_info in > libHSHDBC-sqlite3-1.1.3.0.a(Utils.o) > "_sqlite3_bind_null", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall11_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_bind_text", referenced from: > _sqlite3_bind_text2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_column_name", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall6_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_total_changes", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall13_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_close", referenced from: > _sqlite3_close_app in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_column_text", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall8_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_column_type", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall7_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_libversion", referenced from: > _r6xt_info in libHSHDBC-sqlite3-1.1.3.0.a(Connection.o) > "_sqlite3_finalize", referenced from: > _sqlite3_prepare2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > _sqlite3_finalize_app in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_changes", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall12_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_open", referenced from: > _sqlite3_open2 in libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_bind_parameter_count", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall2_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_step", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall3_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_busy_timeout", referenced from: > _sqlite3_busy_timeout2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > "_sqlite3_column_count", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall5_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_reset", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall4_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_column_bytes", referenced from: > > _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziStatement_zdwccall9_info in > libHSHDBC-sqlite3-1.1.3.0.a(Statement.o) > "_sqlite3_prepare", referenced from: > _sqlite3_prepare2 in > libHSHDBC-sqlite3-1.1.3.0.a(hdbc-sqlite3-helper.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > > > > > On Jan 4, 2008, at 6:13 PM, Christian Maeder wrote: > >> Please post the full ld error message >> (also to glasgow-haskell-users(a)haskell.org) >> >> C. >> >> manu wrote: >>> Hi Christian >>> >>> yes it did >>> >>> but, when i tried to compile one of my cgi script where I happen to use >>> HDBC.Sqlite3 >>> it fails with similar 'ld' errors... >>> >>> so I can compile HDBC-Sqlite3, but not programs that use the package... >>> >>> Thanks >>> >>> Emmanuel >>> >>> >>> On Jan 4, 2008, at 11:21 AM, Christian Maeder wrote: >>> >>>> Did a final "runhaskell Setup.lhs install" work for you, Emmanuel? >> >> >

1 0

binary-dists for ghc-6.8.2
by Christian Maeder 07 Jan '08

07 Jan '08

Dear all, I've built binary distributions for Mac OS 10.4 (Tiger) based on (better supported) GMP and GNUreadline frameworks and for Solaris 10. http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar… http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.… The frameworks under http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm should do. The Mac binaries have been built using gcc version 4.0.1 (Apple Computer, Inc. build 5367) and a patched Linker.lhs from http://hackage.haskell.org/trac/ghc/ticket/1798 (also the files compiler/main/DriverPipeline.hs and utils/hsc2hs/Main.hs are patched according to http://hackage.haskell.org/trac/ghc/ticket/1395) The PPC binary still features: http://hackage.haskell.org/trac/ghc/ticket/1845 The PPC ghc can be used on Intel Macs with the additional options: -optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc (but that's slower than an i386 binary). The Intel-Mac binary has also a patched file rts/Exception.cmm for http://hackage.haskell.org/trac/ghc/ticket/1980 (although I don't know if it is a Mac problem at all.) The Solaris 10 binaries have been built using gcc-4.2.2 http://www.dfki.de/sks/hets/pc-solaris/versions/ghc-6.8.2-i386-unknown-sola… http://www.dfki.de/sks/hets/solaris/versions/ghc-6.8.2-sparc-sun-solaris2.t… The sparc binary was built on a "sun4u sparc SUNW,Sun-Fire-280R" using: SRC_HC_OPTS += -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc Maybe these binary-dists are somehow useful. Christian

4 8

GHC 6.8.1 port on FreeBSD-amd64?
by Wilhelm B. Kloke 07 Jan '08

07 Jan '08

As I have got an amd64 machine again, I am returning to my previous porting effort. When I try to build to .hc files on i386 system, I get the following error: > ... > gmake[2]: Entering directory `/usr/home/wb/ghc-6.8.1/libraries/unix' > ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build -H32m -O0 -fasm -Rghc-timing -keep-hc-files -O -c dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o -ohi dist/build/System/Posix/Process.hi > Prologue junk?: .type s32x_ret, @function > s32x_ret: > pushl %ebp > movl %esp, %ebp > > <<ghc: 114363808 bytes, 9 GCs, 2951168/5799936 avg/max bytes residency (2 samples), 33M in use, 0.00 INIT (0.00 elapsed), 0.78 MUT (2.33 elapsed), 0.20 GC (0.23 elapsed) :ghc>> > gmake[2]: *** [dist/build/System/Posix/Process.o] Fehler 255 > gmake[2]: Leaving directory `/usr/home/wb/ghc-6.8.1/libraries/unix' > gmake[1]: *** [make.library.unix] Fehler 2 > gmake[1]: Leaving directory `/usr/home/wb/ghc-6.8.1/libraries' > gmake: *** [stage1] Fehler 2 which I don't understand at all. The build of ghc-6.8.1 for native use on a FreeBSD-6.2 i386 did not cause any problems. Perhaps someone else has done the porting work already. Please give me a note, if anybody is able to provide me a set of files to get the bootstrap further. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key

3 4