October 2006 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Replacement for GMP: Update
by Peter Tanski 24 Jan '07

24 Jan '07

Simon PJ, Simon, Esa and John, Here is an update on what I have been doing so far in making a grand attempt to replace GMP. (1) evaluate replacement libraries LibTomMath: Pros- * has all the operators GMP offered Cons- * slow; about half as fast as OpenSSL in my tests for simple mathematical operations, much slower if you account for time to write or resize memory. (There is another MP library, which LibTomMath is based on, that is also very slow--student work) * not even reentrant; needs significant modification * beta-release; needs a bit of work to get it to production level * configuration needs to be written (not really portable, messy) ARPREC: Pros- * very fast (essentially does everything through the Floating Point Unit of a CPU) * complex mathematical operations * very precise * already thread safe (through C++ thread-safe statics) Cons- * no bitwise operations (not even left and right-shifts) * difficult configuration (everything runs by setting a precision level; ("precision level" ~= number of words (doubles) in array) it does not automatically resize memory; conversion from MP Real to Integer relies specially on careful precision-level) * memory inefficient (underestimates the number of real digits you can fit into a double, i.e., a 64-bit double has 48 bits of precision, holding about 9.6 digits per byte, resulting in an 848-byte array to hold an MP number with 1000 digits). OpenSSL: Crypto++ (http://www.eskimo.com/~weidai/cryptlib.html) Botan (http://botan.randombit.net/) Pros- * all of these are fast, since all use Integers to support cryptography; (Crypto++ and Botan are C++ crypto-libraries, all licenses good) * all of these provide most basic mathematical operations Cons- * none of these provide &, |, ^(xor) bitwise operators * Botan has least mathematical operators of the three * none provide lcm operator * all would realistically have to have the Integer libraries stripped out of the distribution and repackaged for GHC Summary: I finally settled on modifying OpenSSL, since that would be the easiest to work with under GHC's hood (plain C code, not C++). I have to: a. make OpenSSL's BN thread-safe (add thread local storage, at least) b. optimally add configure-conditional parallelism to BN (through PVM) c. add &, |, ^, lcm and a few other operations d. separate the BN from the rest of OpenSSL and rename the symbols to avoid conflicts (necessary because I have to modify the library anyway) (2) work on GHC: * finally understand C--; know what I need to modify * work through Makefiles: touch and go; I haven't mapped out all the variable settings from configure.in on down when it comes to DLLs Comment: for the Makefile in ghc/rts, in lines 300-346, GC_HC_OPTS += -optc-O3 --isn't this problematic? gcc, from -O2 on includes -fgcse which may *reduce* runtime performance in programs using computed gotos; -fgcse is actually run twice, because -frerun-cse-after-loop is also set at -O2. Would it be better to pass individual flags, such as -funroll-loops and -falign-loops=16 (ppc, Intel setting)? (3) I have been looking at how to implement a dual-constructor-in-a- pointer for Integer (i.e., merge constructors of small Integers and big Integers into the Int#). Would that solution be workable or might it break current Haskell programs? Just a thought. -Peter

11 29

RE: [Haskell] Expecting more inlining for bit shifting
by roconnor＠theorem.ca 05 Dec '06

05 Dec '06

On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: > Turns out that 'shift' is just too big to be inlined. (It's only called > once, but you have exported it too.) > > You can see GHC's inlining decisions by saying -ddump-inlinings. > > To make GHC keener to inline, use an INLINE pragma, or increase the > inlining size threshold e.g. -funfolding-threshold=12 Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? PS, is there a way to mark an imported instance of a class function (Data.Bits.shift for Data.Word.Word32) to be inlined? -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

6 18

Hacking on GHC interactively with GHCi
by Clemens Fruhwirth 25 Nov '06

25 Nov '06

Hello everyone, I would like to hack on GHC interactively. My aim is to load ghc into ghci and start hacking a source file in one emacs buffer, while the other hosts an inferior-haskell session connected to GHCi. I really like this kind of development style and found it to be way more productive than "edit/compile/test/restart from edit". To context of the following is the compiler/ subtree, as I'm primarily interested in that. I tried to: * load all GHC compiler source files into ghci, fails because of occassional unboxed types (bytecode generated can't deal with them) * load all .o files (with unboxed types) and load a modified source in interpreted mode. This doesn't work well because for that approach you need to mix the source with the object in the same directory (copy compiler/**/*.[l]hs to stage1 or stage2). This, fails because there seem to be some sources missing, I have not investiged where the .o-boot files come from like compiler/stage2/basicTypes/OccName.o-boot. With source files, GHCi just ignores the existing .o file (resumable because it can't check whether the .o file is more recent than the source file) * load "ghci -package ghc" and load main/Main.hs. This work pretty well, but only in comparsion to the other approaches -- that means loading does not fail. Invoking ":main -c foobar.hs" freezes the ghci session. With this approach I can not change any module withing the packaged ghc. Is that true? But that's what I want to do (in particular to the parser part). So, before I start to work towards a particular end of these 3 approaches, is there anyone how develops ghc in an interactive way using ghci with partial :reload-ing of modules? The GHC user guide has a good illustration of what I'm looking for http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-compiled.html Any hint is appreciated. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

3 3

Re: Bad control characters in GHCi 6.6 (Mac OS X PPC)
by Björn Buckwalter 21 Nov '06

21 Nov '06

On 10/19/06, Simon Marlow <simonmar(a)microsoft.com> wrote: > See this page that I just created: > > http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX I tried these instructions, first by using my existing (darwinports) readline in /opt/local, and when that failed by first installing readline in /usr/local per the instructions. Neither fixed the problem. I don't know why but perhaps I failed to remove the traces of my initial install completely. In the end I gave up and installed Greg Heartsfield's binary package which remedied my problems (thanks Greg!). Thanks anyway Simon, -Bjorn Buckwalter

4 4

ghc-testsuite-6.6 on Macs
by Christian Maeder 16 Nov '06

16 Nov '06

Did someone run the test-suite of the binary distributions? http://www.haskell.org/ghc/dist/6.6/ghc-6.6-ppc-apple-darwin.tar.gz http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 I've build a (ppc-) mac-distribution from sources and my results are shown below. I had the following 3 unexpected failures under linux, too (by using "make TEST_HC=<installed ghc>" and the <installed ghc> was from http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2) cg058(ghci) ghcpkg01(normal) ghcpkg03(normal) I thought the failure signals002(ghci) was related to http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/10947 In fact, I needed to kill the ghc-process to continue the tests. The test files cc004.hs and ffi012.hs failed with several messages of the form: calling convention not supported on this architecture: stdcall When checking declaration: foreign import stdcall safe "wrapper" wrap_f :: F -> IO (FunPtr F) However, they did not make it into the summary Cheers Christian OVERALL SUMMARY for test run started at Mon Oct 23 14:54:15 CEST 2006 1455 total tests, which gave rise to 6441 test cases, of which 0 caused framework failures 1126 were skipped 5242 expected passes 55 expected failures 3 unexpected passes 15 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) Unexpected failures: barton-mangler-bug(opt) cabal02(normal) cg058(ghci) conc019(opt,profasm) conc024(opt) ffi009(ghci) forkprocess01(ghci) galois_raytrace(opt,prof) ghcpkg01(normal) ghcpkg03(normal) joao-circular(prof,profasm) signals002(ghci)

4 7

RE: [Haskell] Deferred instance declarations (serialization ofexistential boxes)
by Simon Peyton-Jones 10 Nov '06

10 Nov '06

[redirecting to GHC users, since it's a GHC-specific question] Misha | I asked this question on haskell-cafe once, but my post didn't get any | responses, so I try once again here explaining a bit more where my | problem comes from. I was at ICFP. | Suppose I have a monomorphic datatype, say T and want to do something | with it, which depends on an instance of class C being defined for T. | However I can only provide this instance later, in a different module. | So I would like to write something like | | > f :: C T => T -> T | or | > instance C T => C T' where | > -- a body that uses functions from C T There is no reason in principle why this isn't ok. But there is a practical reason why things are the way they are. Generally, GHC tries to share constraints as much as possible, so that a (C T) constraint in one function right hand side is satisfied by the same binding as another (C T) constraint from another right hand side. So in general, GHC "floats" constraints outwards if they don't mention any type variables bound by the forall's of the type signature. The whole question of the interaction of type signatures and constraints is quite delicate, and I rather doubt I'll change this behaviour soon. (And no one else has asked for it before, I think.) But I think the case is stronger for top-level constraints, and I will bear it in mind. If you would like to open a Trac feature request, please do so. Concerning your application | I am having a box like | > data Box = forall a. Cxt a => Box a | and want to write a Read instances for it. I don’t see how it helps to defer the Read instance. Reading existentials is bound to be difficult, or even impossible. I guess it depends what is in Cxt. Simon

2 2

Link error under solaris 8
by Christian Maeder 08 Nov '06

08 Nov '06

Hi, I get a link error under sparc sun Solaris 8, when linking my stage2 compiler. I have "undefined reference to" a couple of mathematical function like powf, tanhf, coshf, sinhf, atanf, acosf, asinf, tanf, cosf, sinf, sqrtf, logf, and expf Is libm version 2 needed? The stage1 compiler was content with libm version 1. Cheers Christian -bash-3.00$ uname -a SunOS euklid 5.8 Generic_117350-41 sun4u sparc SUNW,Ultra-4 -bash-3.00$ ldd compiler/stage1/ghc-6.6 libdl.so.1 => /usr/lib/libdl.so.1 libm.so.1 => /usr/lib/libm.so.1 libgmp.so.3 => /usr/local/lib/libgmp.so.3 libc.so.1 => /usr/lib/libc.so.1 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 ../compiler/stage1/ghc-inplace -o stage2/ghc-6.6 -H16m -O -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -DBREAKPOINT -threaded stage2/main/Main.o /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__151.o): In function `s9W7_info': ghc29001_0.hc:(.text+0x290): undefined reference to `powf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__152.o): In function `s9Wv_info': ghc29001_0.hc:(.text+0x28c): undefined reference to `tanhf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__153.o): In function `s9WK_info': ghc29001_0.hc:(.text+0x288): undefined reference to `coshf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__154.o): In function `s9WZ_info': ghc29001_0.hc:(.text+0x288): undefined reference to `sinhf' [...] /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__237.o): In function `s85X_info': ghc29001_0.hc:(.text+0x974): undefined reference to `atanf' collect2: ld returned 1 exit status <<ghc: 19353284 bytes, 3 GCs, 100700/100700 avg/max bytes residency (1 samples), 15M in use, 0.01 INIT (0.00 elapsed), 0.33 MUT (34.47 elapsed), 0.03 GC (0.09 elapsed) :ghc>> gmake[3]: *** [stage2/ghc-6.6] Error 1 gmake[3]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6/compiler' gmake[2]: *** [stage2/ghc-6.6] Error 2 gmake[2]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6/compiler' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6' gmake: *** [bootstrap2] Error 2

1 1

Parallelism in 6.6 and seq vs. pseq
by Simon Marlow 08 Nov '06

08 Nov '06

I just noticed, thanks to some testing of the parallelism support in 6.6 by Satnam Singh, that Control.Parallel exports seq when in fact it should probably export pseq. The difference is subtle. The semantics of seq and pseq are identical; however, GHC can see that seq is strict in both its arguments and hence could choose to evaluate them in either order, whereas pseq is only strict in its first argument as far as the strictness analyser is concerned. The point is that pseq is useful for controlling evaluation order, which is what you want for adding parallelism to a program. seq, on the other hand, is not useful for controlling evaluation order. The documentation in 6.6 is also incorrect on this point. pseq is currently not exported by Control.Parallel, this is an oversight on my part, you have to import it from GHC.Conc for now. For 6.8 we'll export pseq from Control.Parallel instead of seq. Incedentally, the fixity of par is also wrong in 6.6: it should be infixr 0, but in fact it has the default fixity of infixl 0. This means if you write an expression like 'x `par` y `seq` z', it isn't doing what you think. Workaround: either use parentheses, or define your own par with the right fixity. Cheers, Simon

4 15

Re: ghc-6.6 under sparc-sun-solaris
by Christian Maeder 03 Nov '06

03 Nov '06

Duncan Coutts schrieb: >> So "ghc -split-objs" works now with either -optc-mcpu=v8 or >> -opta-mcpu=v9 (or even -opta-mcpu=ultrasparc). >> >> Where should I place what so that my stage1 inplace-compiler works >> without "SplitObjs=NO" in mk/build.mk? > > Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Two further questions: 1. Without "SplitObjs=NO" in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line? 2. Will the options given in SRC_HC_OPTS be burned into the final stage2 compiler or will I have to supply these options explicitely again? Thanks Christian P.S. building under solaris requires over 2GB memory (and takes a day)

2 5