April 2011 - 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

MonoLocalBinds and hoopl
by Edward Z. Yang 19 Jun '11

19 Jun '11

Hello all, Here's an experience report for porting hoopl to manage MonoLocalBinds. The Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of code writing, along the lines of this: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block where f n = FF3 $ ff n m n = FF3 $ fm n l n = FF3 $ fl n FF3 f `cat` FF3 f' = FF3 $ f' . f f, m, l and cat are polymorphic functions that are only used once in the main expression, and are floated outside to improve readability. However, when MonoLocalBinds is turned on, these all become monomorphic and the definitions fail. In contrast, this (uglier) version typechecks: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) (FF3 . fl) (\(FF3 f) (FF3 f') -> FF3 $ f' . f)) block One suggestion that I had was that we should generalize local bindings that are only used once, but Marlow pointed out that this would make the typechecker more complex and I probably would agree. As a userspace developer, I have two options: 1. Bite the bullet and put in the polymorphic type signatures (which can be quite hefty) 2. Inline the definitions 3. Move the polymorphic functions into the global namespace (3) and (2) are not so nice because it breaks the nice symmetry between these definitions, which always define f, m, l for the many, many definitions in Hoopl of this style. Cheers, Edward

6 8

ghc cyclic import error confusing
by Evan Laforge 16 Jun '11

16 Jun '11

I've found ghc's cyclic import error to be rather confusing, and I finally took the time to understand why. Here's an example: Module imports form a cycle for modules: Cmd.Cmd (./Cmd/Cmd.hs) imports: Perform.Midi.Instrument Instrument.MidiDb Instrument.Db Perform.Midi.Instrument (./Perform/Midi/Instrument.hs) imports: Cmd.Cmd Instrument.MidiDb (./Instrument/MidiDb.hs) imports: Perform.Midi.Instrument Instrument.Db (./Instrument/Db.hs) imports: Instrument.Search Instrument.MidiDb Perform.Midi.Instrument Instrument.Search (./Instrument/Search.hs) imports: Instrument.MidiDb Perform.Midi.Instrument It seems to be in a strange order and mentions extraneous modules. I would find this much easier to read: Perform.Midi.Instrument -> Cmd.Cmd -> Instrument.MidiDb -> Perform.Midi.Instrument Instead, the order goes Cmd.Cmd -> Instrument.MidiDb, and then goes backwards to Perform.Midi.Instrument -> Cmd.Cmd. Then it goes forward again to Instrument.MidiDb -> Perform.Midi.Instrument. So the order makes you jump around if you want to trace the import chain. The duplicated module that joins the cycle is not visually highlighted. Whats more, it further confuses the eye by merging in multiple loops. I suppose it could be useful to include additional loops, but I would find it easier to read if they were included on their own line, such as: Cmd.Cmd -> Instrument.Db -> Instrument.Search -> Perform.Midi.Instrument -> Cmd.Cmd However, I think probably the shortest loop is the most interesting one, and if there are multiple shortest loops, simply picking one randomly is likely to be sufficient. Thoughts?

5 5

Tracing idea
by Edward Z. Yang 12 May '11

12 May '11

I was thinking it might be useful if we had a per-thread circular buffer in memory for which we pushed a pointer to the info table we had just entered. In the event of a crash, you could dump the contents of the buffer to see what code had been recently executed. To reduce overhead, one might only need to record this information when we do a tail call, and not when the path can be reconstructed from the stack. (Obviously, you'd need to compile in debug mode, and you'd probably want to also add an RTS flag). What do people think? Cheers, Edward

3 4

Are FFI calls interruptible?
by Bas van Dijk 04 May '11

04 May '11

Hello, Quick question: are safe/unsafe FFI calls interruptible? Thanks, Bas

3 6

Broken ghc-7.0.3/vector combination?
by Daniel Fischer 03 May '11

03 May '11

Investigating the appearance of NaN in criterion's output, I found that NaNs were frequently introduced into the resample vectors when the resamples were sorted. Further investigation of the sorting code in vector-algorithms revealed no bugs there, and if the runtime was forced to keep a keen eye on the indices, by replacing unsafeRead/Write/Swap with their bounds-checked counterparts or by 'trace'ing enough of their uses, the NaNs did not appear. I could not reproduce the behaviour with ghc-7.0.1 (using exactly the same versions of the involved libraries), ghc-7.0.2 (different criterion release, the other libraries identical) or unoptimised compilation with 7.0.3 (no NaNs encountered in some 100+ testruns with varying input). So, is it possible that some change in ghc-7.0.3 vs. the previous versions caused a bad interaction between ghc-optimisations and vector fusion resulting in bad vector reads/writes?

9 14

Incrementally consuming the eventlog
by Johan Tibell 01 May '11

01 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