- Glasgow-haskell-users

Elimination of absurd patterns (reformatted)
by C Rodrigues 03 May '11

03 May '11

I'm re-sending this e-mail, hopefully with proper line breaks this time. I was experimenting with using GADTs for subtyping when I found something interesting. Hopefully someone can satisfy my curiosity. Here are two equivalent GADTs. My understanding was that GHC would translate "Foo" and "Bar" into isomorphic data types. However, GHC 6.12.3 generates better code for 'fooName' than for 'barName'. In 'fooName', there is no pattern match against 'FooExtra'. In 'barName', there is a pattern match against 'BarExtra'. What makes these data types different? data Tag data TagExtra -------- data Foo a where Foo :: String -> Foo a FooExtra :: IORef String -> Foo TagExtra -- The cmm code for fooName does not match against 'FooExtra' fooName :: Foo Tag -> String fooName (Foo s) = s -------- data Bar a where Bar :: String -> Bar a BarExtra :: a ~ TagExtra => IORef String -> Bar a -- The cmm code for barName will try to pattern-match against 'BarExtra' barName :: Bar Tag -> String barName (Bar s) = s

2 1

(no subject)
by hsing-chou chen 02 May '11

02 May '11

http://www.buonviaggioitaly.com/modules/mod_osdonate/myhome.html

1 0

Incrementally consuming the eventlog
by Johan Tibell 02 May '11

02 May '11

Hi, We were discussing how to consume the eventlog incrementally on #ghc today. Would it be feasible to offer an API (e.g. GHC.EventLog) that allows programs to register for events that occur in the program? Programs would register listeners like so: registerEventListener (\ event -> doSomethingWith event) The current write-to-file system could be implemented in terms of this API. We could even allow event logging to be turned on/off from within the application, allowing developers to attach to a running application, enable event logging, diagnose the app, and then turn of event logging again. The RTS would invoke listeners every time a new event is written. This design has many benefits: - We don't need to introduce the serialization, deserialization, and I/O overhead of first writing the eventlog to file and then parsing it again. - Programs could monitor themselves and provide debug output (e.g. via some UI component). - Users could write code that redirects the output elsewhere e.g. to a socket for remote monitoring. Would invoking a callback on each event add too big of an overhead? How about invoking the callback once every time the event buffer is full? Johan

5 9

Package management
by Brandon Moore 01 May '11

01 May '11

Based on my own misadventures and Albert Y. C. Lai's SICP (http://www.vex.net/~trebla/haskell/sicp.xhtml) it seems the that root of all install problems is that reinstalling a particular version of a particular package deletes any other existing builds of that version, even if other packages already depend on them. Deleting perfectly good versions seems to be the root of all package management problems. There are already hashes to keep incompatible builds of a package separate. Would anything break if existing packages were left alone when a new version was installed? (perhaps preferring the most recent if a package flag specifies version but not hash). For example, It seems the butterfly effect http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/ could be avoided if the package database was allowed to simultaneously contain a "twittertags-1.0.0-hashA" and "twittertags-1.0.0-hashB" built against different dependencies. The obvious difficulty is a little more trouble to manually specify packages. Are there any other problems with this idea? Brandon

3 3

performance issues in simple arithmetic code
by Denys Rtveliashvili 28 Apr '11

28 Apr '11

Hi, While trying to figure out why some of my code is very slow I have found that it is something related to division. Digging a bit deeper I found an example which shows some unexpected magic and a lack of the expected one. Before raising any tickets in trac I would like to consult with you regarding what I see. Maybe I am misunderstanding the way GHC is supposed to work. ------------------- module Test where import Data.Int import GHC.Exts import GHC.Prim foo :: Int -> Int foo a = let b = a `quot` 1111 c = b `quot` 1113 d = c `quot` 1117 in d bar :: Int -> Int bar !a' = let !(I# a) = a' !(b) = quotInt# a 1111# !(c) = quotInt# b 1113# !(d) = quotInt# c 1117# in I# d ------------------- Here 'foo' is a function written in a common way and 'bar' is essentially identical one, written in a low-level style. * My understanding is that these functions are equivalent in terms of what they do. The only difference is in the code being generated. Unexpected magic is in the Core dump: ------------------- Test.$wfoo = \ (ww_sxw :: GHC.Prim.Int#) -> case ww_sxw of wild1_ax0 { __DEFAULT -> case GHC.Prim.quotInt# wild1_ax0 1111 of wild2_Xxc { __DEFAULT -> case GHC.Prim.quotInt# wild2_Xxc 1113 of wild3_Xxt { __DEFAULT -> GHC.Prim.quotInt# wild3_Xxt 1117; (-9223372036854775808) -> (-8257271295304186) }; (-9223372036854775808) -> (-7418931981405) }; (-9223372036854775808) -> (-6677706553) } Test.bar = \ (a'_ah5 :: GHC.Types.Int) -> case a'_ah5 of _ { GHC.Types.I# ipv_ste -> GHC.Types.I# (GHC.Prim.quotInt# (GHC.Prim.quotInt# (GHC.Prim.quotInt# ipv_ste 1111) 1113) 1117) } ------------------- Question 1: what is the meaning of those magic numbers -9223372036854775808, -6677706553, -7418931981405, -8257271295304186? Question 2: under which circumstances those strange branches of execution will be used and what those results would mean? Question 3: why is the Core for 'foo' so different to 'bar'? The lack of expected magic is in the assembler code: ------------------- addq $16,%r12 cmpq 144(%r13),%r12 ja .Lcz1 movl $1117,%ecx movl $1113,%r10d movl $1111,%r11d movq 7(%rbx),%rax cqto idivq %r11 cqto idivq %r10 cqto idivq %rcx movq $ghczmprim_GHCziTypes_Izh_con_info,-8(%r12) movq %rax,0(%r12) leaq -7(%r12),%rbx addq $8,%rbp jmp *0(%rbp) ------------------- Question: can't it use cheap multiplication and shift instead of expensive division here? I know that such optimisation is implemented at least to some extent for C--. I suppose it also won't do anything smart for expressions like a*4 or a/4 for the same reason. With kind regards, Denys Rtveliashvili

5 5

parsing types
by Ranjit Jhala 27 Apr '11

27 Apr '11

Hi all, can someone give me a hint as to the best way to parse a type from a string. Ideally, I'd like a function stringType :: String -> Maybe Type or possibly, stringType :: (GhcMonad m) => String -> m (Maybe Type) such that, stringType s == Just t if in the current GHC context the string s is the name of the type t. For example, I'd like: stringType "Int" to return a value equal to intTy (from TysWiredIn). My investigations have led me to parseType :: P (LHsType RdrName) and I suspect that with some work (mainly creating an appropriate PState, and mapping the name back, I can extract what I want, but I was wondering if there is some simpler route that I've overlooked. Thanks! Ranjit.

4 6

Perplexing GHC-7.0.3 behavior with hairy type-level code (regression from 6.12.3??)
by Bjorn Buckwalter 26 Apr '11

26 Apr '11

Hello all, I am doing some fairly hairy type-level stuff with FunctionalDependencies, UndecidableInstances, and other. Without going into details I have the following function which compiles fine: vecMat :: (Transpose m m', MatrixVector m' v v', Num a) => Vec v a -> Mat m a -> Vec v' a vecMat v m = transpose m `matVec` v However, I am perplexed by the following: 1. This does NOT compile despite the type signature being identical to that of 'vecMat': vecMat2 :: (Transpose m m', MatrixVector m' v v', Num a) => Vec v a -> Mat m a -> Vec v' a vecMat2 v m = vecMat v m The error message is along the lines of the below where 'HMap ...' is the context for the MatrixVector instance... I'll provide more details as needed. Could not deduce (HMap (DotProd, v) m' v') arising from a use of `vecMat' from the context (Transpose m m', MatrixVector m' v v', Num a) bound by the type signature for vecMat2 :: (Transpose m m', MatrixVector m' v v', Num a) => Vec v a -> Mat m a -> Vec v' a 2. If I omit the type signature the definition of 'vecMat2' does compile: vecMat2 v m = vecMat v m 3. If I omit the second argument it also compiles: vecMat2 v = vecMat v 4. However, if I omit both arguments it does NOT compile: vecMat2 = vecMat So I guess I have two questions. First: why would 1 not compile? Second: why are 2, 3, and 4 not equivalent? Pointers to relevant documentation welcome. I broke my GHC-6.12.3 installation when upgrading to the latest HP with GHC-7.0.3 so I cannot test 2, 3, and 4 but I know that 1 DID compile on GHC-6.12.3. Is the change of behavior in GHC-7.0.3 a bug or a bug fix? I'll be happy to elaborate on the code if it would be useful, and try to find a minimal example. But I wanted to check if the behavior I am seeing makes any sense at all first. In case you cannot wait the 'matVec' definition is from: https://github.com/bjornbm/dimensional-vectors/blob/master/Numeric/Units/Di… Thanks, Bjorn

2 1

Head does not build on OS X
by Johan Tibell 22 Apr '11

22 Apr '11

Here's the error. I've run make clean, but it didn't help: "/usr/bin/ghc" -H64m -O -fasm -package-conf libraries/bootstrapping.conf -package-name Cabal-1.11.0 -hide-all-packages -i -ilibraries/Cabal/. -ilibraries/Cabal/dist-boot/build -ilibraries/Cabal/dist-boot/build/autogen -Ilibraries/Cabal/dist-boot/build -Ilibraries/Cabal/dist-boot/build/autogen -Ilibraries/Cabal/. -optP-include -optPlibraries/Cabal/dist-boot/build/autogen/cabal_macros.h -package array-0.3.0.2 -package base-4.3.1.0 -package containers-0.4.0.0 -package directory-1.1.0.0 -package filepath-1.2.0.0 -package old-time-1.0.0.6 -package pretty-1.0.1.2 -package process-1.0.1.5 -package unix-2.4.2.0 -fwarn-tabs -Wall -fno-ignore-asserts -XHaskell98 -XCPP -no-user-package-conf -rtsopts -odir libraries/Cabal/dist-boot/build -hidir libraries/Cabal/dist-boot/build -stubdir libraries/Cabal/dist-boot/build -hisuf hi -osuf o -hcsuf hc -c libraries/Cabal/./Distribution/Simple/PreProcess/Unlit.hs -o libraries/Cabal/dist-boot/build/Distribution/Simple/PreProcess/Unlit.o "/usr/bin/ghc" -H64m -O -fasm -package-conf libraries/bootstrapping.conf -package-name hoopl-3.8.7.0 -hide-all-packages -i -ilibraries/hoopl/src -ilibraries/hoopl/dist-boot/build -ilibraries/hoopl/dist-boot/build/autogen -Ilibraries/hoopl/dist-boot/build -Ilibraries/hoopl/dist-boot/build/autogen -Ilibraries/hoopl/. -optP-include -optPlibraries/hoopl/dist-boot/build/autogen/cabal_macros.h -package base-4.3.1.0 -package containers-0.4.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -no-user-package-conf -rtsopts -odir libraries/hoopl/dist-boot/build -hidir libraries/hoopl/dist-boot/build -stubdir libraries/hoopl/dist-boot/build -hisuf hi -osuf o -hcsuf hc -c libraries/hoopl/src/Compiler/Hoopl/Shape.hs -o libraries/hoopl/dist-boot/build/Compiler/Hoopl/Shape.o "/usr/bin/ghc" -H64m -O -fasm -package-conf libraries/bootstrapping.conf -i -iutils/unlit/. -iutils/unlit/dist/build -iutils/unlit/dist/build/autogen -Iutils/unlit/dist/build -Iutils/unlit/dist/build/autogen -no-user-package-conf -rtsopts -c utils/unlit/unlit.c -o utils/unlit/dist/build/unlit.o "inplace/bin/mkdirhier" utils/unlit/dist/build/tmp//. make[1]: *** No rule to make target `settings', needed by `inplace/lib/settings'. Stop. make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

2 2

GHC/LLDB integration
by William Knop 21 Apr '11

21 Apr '11

Hello all, I've been using LLDB for a few weeks now, initially acquainting myself with its python bindings. It occurred to me early on that they might integrate into GHC's testsuite well, so I began writing a driver. The idea was to encapsulate the launched haskell processes in LLDB and generate more useful debugging information for failed tests (I'd previously been hunting down a few spurious segfaults). However, LLDB is quite immature and currently lacking such capabilities as generating core files, among other things. But while searching for core file generation, I ended up discovering that it is to eventually be implemented as a native plugin. It turns out that the plugin system allows for a lot of extensibility, including language and ABI extension. So I started digging into that and just recently began working on adding a GHRuntime plugin which should allow for demangling of symbols (easy), analysis and description of info tables and call graphs (hard), etc. So before I get too far into it, and because I am not a GHC guru, I'd like to gauge it's ultimate usefulness amongst the community. Given that haskell code goes through several stages of transformation, can more useful information be derived from a debugged executable? Or can more useful debug information be emitted by GHC if it can be interpreted by a purpose-made debugger plugin? If so, what information and functionality would be desirable? Ideas and comments are most welcome. Will

3 3

Type-level operators
by Stefan Holdermans 20 Apr '11

20 Apr '11

Simon, Regarding the note you attached to the Trac ticket on the pretty-printing of kind ascriptions (http://hackage.haskell.org/trac/ghc/ticket/5141#comment:2) > Note, though, that it's likely that we're considering making operators > like '*' into type ''constructors'' rather that type ''variables'. This > is inconsitent with terms, but is jolly convenient: > {{{ > data a + b = Left a | Right b > }}} > Of course there'll be a flag. But let us know if you think that having > operators be type variables is very useful. (I tend to think it's more > confusing than useful.) I myself am perfectly alright with being "forced" to write {{{ data a :+: b = Left a | Right b }}} Although I don't have a *convincing* example of the usefulness of operators as type variables, I like the idea of consistency with the term level: IMO it keeps things predictable. And even as it may not qualify as convincing, I do remember having written code similar to {{{ data (f :+: g) a = Inl (f a) | Inr (g a) data (f :*: g) a = f a :*: g a class FunctorOp ((&) :: (* -> *) -> (* -> *) -> (* -> *)) where ... instance FunctorOp (:+:) where ... instance FunctorOp (:*:) where ... class FunctorOp (&) => CommOp (&) where comm :: f & g -> g & f instance CommOp (:+:) where ... instance CommOp (:*:) where ... f :: (CommOp (&), Functor f, Functor g) -> f & g -> ... f ... = ... }}} All this, of course, just to put in my tuppence worth. Cheers, Stefan

1 0