March 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

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

Using the GHC heap profiler
by Tim Docker 19 Apr '11

19 Apr '11

My question on the ghc heap profiler on stack overflow: http://stackoverflow.com/questions/5306717/how-should-i-interpret-the-outpu… remains unanswered :-( Perhaps that's not the best forum. Is there someone here prepared to explain how the memory usage in the heap profiler relates to the "Live Bytes" count shown in the garbage collection statistics? Many thanks, Tim

6 12

Strange performance effects with unsafePerformIO
by Björn Peemöller 08 Apr '11

08 Apr '11

Hello, we have a strange performance behaviour when we use unsafePerformIO, at least with GHC 6.12.3 and 7.0.1. Please consider the example program following at the end of this post. Running the original code the execution time is about 26 seconds, while uncommenting one (or both) of the comments shrinks it to about 0.01 seconds on our machine. Is there an explanation for this effect? Regards, Bjoern -- --------------- module Main where import System.IO.Unsafe traverse [] = return () -- traverse (_:xs) = traverse xs traverse (_:xs) = traverse xs >> return () makeList 0 = [] -- makeList n = () : (makeList (n - 1)) makeList n = () : (unsafePerformIO . return) (makeList (n - 1)) main = traverse $ makeList (10^5)

4 5

Class constraints for associated type synonyms
by Jan-Willem Maessen 01 Apr '11

01 Apr '11

Hi all - I've been trying to construct a class declaration with an associated type synonym, but I'd like to constrain that type to belong to a particular class. Consider the following class: class Monoid m => Constructs c m | c -> m where construct :: m -> c This captures the idea that the collection c ought to be constructed using the monoid m (say if we're doing the construction using the Writer monad)--the functional dependency indicates the desire for the type c to injectively determine the choice of monoid m. For example: newtype ListBuilder a = Builder ([a] -> [a]) deriving (Monoid) instance Constructs [a] (ListBuilder a) where construct (Builder f) = f [] instance (Ord a) => Constructs (Set a) (Set a) where construct = id Now I'd like to be able to do the same thing using an associated type synonym, something like this: class Monoid (GeneratorOf a) => Generable a where type GeneratorOf a :: * -> * construct :: GeneratorOf a -> a Now, it seems I need FlexibleInstances to do this when I'm using an associated type synonym, but I don't need the flexibility when using a multiparameter type class. In both cases the instance constraint involves types that can be injectively inferred (if I have my terminology straight; work with me here) from a single type mentioned in the class head. In particular, I can imagine storing the dictionary for Monoid (GeneratorOf a) in the dictionary for Generable a, and thus allowing context reduction of (Monoid (GeneratorOf tyvar)) to (Generable tyvar). Meanwhile, I think there are things that are permitted by FlexibleInstances that I'd rather *not* have creeping into my programs. Is there a fundamental constraint I'm missing here that requires the full generality of FlexibleInstances? Do I need to use FlexibleInstances whenever I use associated types in my programs? -Jan-Willem Maessen

3 3

ANNOUNCE: GHC version 7.0.3
by Ian Lynagh 31 Mar '11

31 Mar '11

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.3 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 7.0.2, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/release-7-0-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

5 8

FFI and LLVM
by Louis Wasserman 30 Mar '11

30 Mar '11

I'm curious: as I understand it, one of the purposes of the FFI is to allow bindings to "close to the metal" languages. I'm curious what would be involved in letting the FFI provide bindings to LLVM code in Haskell. While I'm at it, I'll mention the most recent reason that this thought occurred to me, which is the complaint in here<http://disciple-devel.blogspot.com/2011/03/real-time-edge-detection-in-hask…> that Haskell can't currently get access to SIMDs, while LLVM does<http://llvm.org/docs/LangRef.html#t_vector>have that access, and I'm trying to think about how I might go about gluing those together. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

3 2

Hackage buildbot: llvm
by Christian Hoener zu Siederdissen 30 Mar '11

30 Mar '11

Hi, could it be that the llvm version used for the hackage buildbot is too old? The newest version of my 'Biobase' library does not compile there: http://hackage.haskell.org/packages/archive/Biobase/0.3.1.0/logs/failure/gh… and this seems to be due to llvm being too old: http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/19397 Gruss, Christian Options in my cabal file (for reference): ghc-options: -Odph if impl(ghc > 6.13) ghc-options: -fllvm

1 0

warning
by Luca Ciciriello 29 Mar '11

29 Mar '11

Hi All. I've installed on my MacOS X 10.6.7 (Xcode4) the new GHC 7.0.3 (64 bit) All works fine, but every time I build my code I get the warning: ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame Is this warning something bad? Thanks. Luca.

1 0