November 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 23 Jan '07

23 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

Unpacking polymorphic fields
by Takano Akio 05 Jan '07

05 Jan '07

Hi, Suppose I have the following two datatypes. data B = B {-# UNPACK #-} !Int data C a = C {-# UNPACK #-} !Char !a If I have a strict function: test :: C B -> IO () I want it to be worker-wrapper-transformed into: $wtest :: Char# -> Int# -> State# RealWorld -> (# State# RealWorld, () #) but GHC actually generates something like: $wtest :: Char# -> B -> State# RealWorld -> (# State# RealWorld, () #) The question is: is there any way to ask GHC to produce the former? If the field is not polymorphic, UNPACK pragma can be used for this, but it does not work in this case. If there is no such way, would it be a reasonable "feature request" to add one? Regards, Takano Akio

2 4

LLVM back end
by Michael T. Richter 04 Jan '07

04 Jan '07

I've been eyeing LLVM[1] as interesting technology -- brief executive summary: a virtual machine suited as the back end of compiler output with optimised native code then coming from it as either JIT-based execution of the LLVM bytecode or as a further compilation step -- and couldn't help but immediately think of the possibility of one of the Haskell compiler projects providing an LLVM code generator. I think this would help in several areas: * it could make porting the compiler to other architectures -- including oddball ones that would be too small to otherwise support -- easier; * it could help remove the nigh-ubiquitous reliance upon GCC as a back-end (while I think that GCC is a pretty good piece of software, I'm not sure it's really suited to its current role as the "do-everything" back end); * it could leverage some of the really interesting work that's going on in optimisation technology by letting one VM's optimiser do the work for any number of languages; * it could improve interaction between source code written in multiple languages. Is this me opening up a Pandora's Box of ignorance here? Or is LLVM potentially interesting? (And were someone motivated into perhaps trying to make an LLVM back-end, where would one start to poke around in, say, the GHC codebase to even begin to implement this? And how insane would they be driven by the process?) [1]http://llvm.org -- Michael T. Richter Email: ttmrichter(a)gmail.com, mtr1966(a)hotpop.com MSN: ttmrichter(a)hotmail.com, mtr1966(a)hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966(a)jabber.cn "I have never seen the poor people being so familiar with their heads of state as they were with [Michele Duvalier]. It was a beautiful lesson for me. I've learned something from it." --Mother Theresa

6 9

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

04 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

raw foregin imports - new backend for jhc: ghc
by John Meacham 04 Dec '06

04 Dec '06

I am working on a new backend for jhc. haskell! well, ghc haskell to be exact. jhc can now compile things with the -fvia-ghc flag and it will pass the optimized program off to ghc for the final compilation. For the most part I use none of the ghc runtime libraries facilities or machinery, all IO is handled via jhc's libraries built upon the FFI so I can ignore ghc's primitives but there are a few cases I am finding a little tricky. IO was pretty easy, I just mapped my World__ type to State# RealWorld, and it all just seems to work. but I am still having a couple issues: I am having trouble with a couple foreign imports that I think should work: here is one: > type World__ = State# RealWorld > > main = IO $ \w -> case getchar w of > (# w', ch #) -> (# w', () #) > > foreign import ccall unsafe getchar :: World__ -> (# World__, Int# #) which produces a ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-linux): resultWrapper (# main:Main.World__{tc rpT}, base:GHC.Base.Int{(w) tc 3J} #) the other is where 'global_argc' is a C symbol. > foreign import ccall "&global_argc" argc :: Addr# I can work around the second trivially, but can't figure out a pleasing way around the first. the other area that is causing trouble is with the numerical primitives, where ghc and jhc differ quite widely on what they do, in jhc, you add new primitives by adding a line to data/primitives.txt like so > Data.Int.Int8, int8_t, int, INT8_MAX, INT8_MIN > Data.Int.Int16, int16_t, int, INT16_MAX, INT16_MIN > ... > Data.Float.Float128, __float128, float, .... every numeric haskell type maps directly to a C type, the compiler treats them as completely opaque otherwise. The end result being that optimized jhc core has a lot of primitive types, and to compile via ghc I need to somehow, portably, map them to ghc primitives, and provide all the peek,poke, etc operations such that they behave correctly as if the underlying c type were being used directly. at the moment, I am flattening everything to Int#, which is not very ideal (but oddly enough, doesn't seem to cause an issue for most programs I have tried) and would like to find something better. Any idea what the shortest path might be to getting things to work? Is there a way to control the C type used to pass values when importing foreign functions in an unboxed manner, ghc seems to have a dearth of primitive integer types, condensing everything down to Int#, so how do I say 'this Int# is actually a C uint16_t' in a foreign import? if that makes sense.. in the meantime. I have one hell of a haskell obfcusiator: check out this translation of > putStrLn "Hello, World!" -fvia-ghc translation: http://repetae.net/computer/jhc/stuff/HelloWorld_code.hs standard C translation via Grin: http://repetae.net/computer/jhc/stuff/HelloWorld_code.c the main (and only) function's c translation extracted: > void > _amain(void) > { > node_t* v1; > node_t* v2; > node_t* v3; > node_t* v4; > node_t* v5; > HsChar v6; > wchar_t v7; > v1 = c24; > goto f922; > /* [p1] */ > f922: 0; > v2 = v1; > if (CJhc__Basics___x3a == v2->any.tag) { > v3 = v2->sCJhc__Basics___x3a.a1; > v4 = v2->sCJhc__Basics___x3a.a2; > v5 = v3; > v6 = v5->sCChar_h.a1; > v7 = ((wchar_t)v6); > (void)putwchar((wchar_t)v7); > v1 = v4; > goto f922; > } else { > return (void)putwchar((wchar_t)10); > } > } John -- John Meacham - ⑆repetae.net⑆john⑈

3 4

TH - splicing with functions defined in the same source file
by Clemens Fruhwirth 04 Dec '06

04 Dec '06

Hi, Template Haskell has the restriction that I can not use a function in splices which is defined in the same source file the splice is in. I want to lift this restriction but at the moment I'm not sure which way to go. For simplicity, I'm not aiming at a dependency analysis approach because of things like f = $(..g..); g = $(..f..). Sure can be caught, but I rather want to start slowly. The idea is to introduce a special marker in HsDecl, that allows all HsDecl after the marker to use functions defined before the marker. Let's call this marker CodeCutDecl. It partitions the list of decls right-associatively and is set explicitly by the programmer. My approach is as follows: Look at the TcRnDriver.lhs:tcRnSrcDecls. The tc_rn_src_decls cuts the code into groups of SpliceDecls. We do something similar, namely we insert an additional grouping step, partitioning groups of HsDecl right-associatively separated by CodeCutDecl. These are in turn are grouped by SpliceDecls as before. Let's call this new grouping function tc_rn_cut_decls. Let preceeeding_decls be the list of HsDecls before the CodeCutDecl marker. We assume preceeding_decls to be renamed and type checked, and initially empty. Whenever entering tc_rn_cut_decls, the preceeding_decls list is compiled and linked. Similar to tc_rn_src_decls, the remaining decls are partitioned into a first_code_cut and remaining_decls group, separated by CodeCutDecl (or exhausition of the list making the reamining_decls list empty). first_code_cut is renamed/type checked. It becomes the preceeding_decls list for the next invokation of tc_src_cut_decls. Compiling preceeding_decls to interactive code should enable the type-checker in the subsequent invocations to use this compiled code in expression/decl splicing. The compilation in detail should happen by a special variant of hscCompileInteractive that does not have a file frontend, but one that directly supplies the compiler with a renamed/type-check source being the preceeding_decls list. The result goes through byteCodeGen via the hscInteractive backend, ending up as an (InteractiveRecomp _ comp_bc, _, _). The comp_bc is transformed into Linkables with [BCOs comp_bc] and linked with linkModules of ghci/Linker.lhs. My question: Is this a sensible approach? Is it sufficient to remove the stage checking in thLocalId to make the type checker use the preceeding BCO-compiled code in its invokations of HscMain.compileExpr? Do you think I have to unload the byte compiled code for some reason I can't think of? Thanks for any guidance, --- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

3 2

OpengGL lockup using GHC 6.6 on Intel Mac
by Joe Jones 02 Dec '06

02 Dec '06

I just installed ghc 6.6 from MacPorts and am trying to use the Haskell ported NeHe OpenGL lessons to play with OpenGL. Unfortunately, when I load the lesson in ghci and then run main the screen turns to garbage and I am forced to power cycle the machine to get back to my desktop. It's not a complete lockup as I an Alt-Tab between apps and the selector UI appears. Selecting an app, though, does nothing and I have no access to the desktop. Anyone know of any issues with the current HOpenGL on Intel? The code comes from this link: http://www.codersbase.com/index.php/Nehe-tuts Don't worry about darcs. You can select the URL for the repo and get the code directly form there. Thanx, joe

4 8

newtype deriving clause ceases to work in HEAD
by Mathieu Boespflug 01 Dec '06

01 Dec '06

Hi, The following code compiles with GHC 6.4.2, but does not typecheck with GHC HEAD pulled on Sunday. module CompilerMonad where import Control.Monad import Control.Monad.Reader import Control.Monad.Error newtype CompilerError = CE String deriving Error newtype CM r a = CM (ReaderT r (ErrorT CompilerError (Either CompilerError)) a) deriving (Monad, MonadReader a, MonadError CompilerError) Compiling the code gives: $ /home/mboes/src/ghc/compiler/stage2/ghc-inplace /tmp/CompilerMonad.hs /tmp/CompilerMonad.hs:10:8: Can't make a derived instance of `MonadReader a (CM r)' (even with cunning newtype deriving: the eta-reduction property does not hold) When deriving instances for `CM' whereas with 6.4.2 $ ghc-6.4.2 --make /tmp/CompilerMonad.hs Chasing modules from: /tmp/CompilerMonad.hs Compiling CompilerMonad ( /tmp/CompilerMonad.hs, /tmp/CompilerMonad.o ) As the above code seemed to be doing what I meant for it to do in 6.4.2, and the docs for HEAD don't seem to have changed, I'm curious as to why this doesn't work in HEAD anymore, and indeed, if this is perhaps a regression? Thanks, Mathieu

2 2

Re: FW: GHC API: Problems with implementing ":reload" for "ghc --make"
by Ian Lynagh 30 Nov '06

30 Nov '06

Hi Brian, Sorry for the delayed response. > My goal is to write a program GhcRemake that works like "ghc --make." > However, instead of terminating after compilation is done, I want the > program to stay open and wait for me to hit <ENTER>. When I hit > <ENTER>, GhcRemake rebuilds the project, just as if I had called "ghc > --make" again with the same arguments. The benefit of such a program > is that GhcRemake should be able to cache a lot of data in memory > between invocations and hopefully be able to do the subsequent > re-makes much faster. Nice idea! > My program seems to work fine when run on itself and when run on > Cabal. But, these two packages seem to be too small to notice any > reduction of building time. So, I decided to test my program by > building the GHC API with it. Unfortunately, it seems like every build > after the first one in the session does the dependency analysis badly, > and things get recompiled unnecessarily. It looks like the problem is caused by recursive module imports. I've added a bug (#1027) with a smaller example of it. Thanks Ian

3 2