November 2012 - Glasgow-haskell-users

Promoted types accepted without language extensions
by Sean Leather 19 Nov '12

19 Nov '12

We discovered that GHC and GHCi (7.4.1) accept promoted types without specifying language extensions (and even when specifying -XHaskell98). For example, promoted lists are accepted: Prelude> type T = [Int,Char] Prelude> :i T type T = (:) * Int ((:) * Char ([] *)) -- Defined at <interactive>:2:6 Also, promoted datatypes: > data N = Z > type T = 'Z I'm guessing you can't use these types anywhere (since they are not kind *), so they won't be very useful, but it seems like this should be disallowed. Regards, Sean

2 1

Generating random type-level naturals
by Eric M. Pashman 17 Nov '12

17 Nov '12

I've been playing around with the idea of writing a genetic programming implementation based on the ideas behind HList. Using type-level programming, it's fairly straighforward to put together a program representation that's strongly typed, that supports polymorphism, and that permits only well-typed programs by construction. This has obvious advantages over vanilla GP implementations. But it's impossible to generate arbitrary programs in such a representation using standard Haskell. Imagine that you have an HList-style heterogenous list of arbitrarily typed Haskell values. It would be nice to be able to pull values from this collection at random and use them to build up random programs. But that's not possible because one can't write a function that outputs a value of arbitrary type. (Or, more or less equivalently, one can't write dependently typed functions, and trying to fake it at the type-level leads to the original problem.) One can, however, write a bit of Template Haskell to construct a random HNat. Something like, hNat 0 = [| hZero |] hNat n = [| hSucc $(hNat (n - 1)) |] Call that with a random positive integer inside a splice and Template Haskell will give you a random HNat that you can use to index an HList. There's your arbitrary Haskell value. But this technique is of little practical value since it only works at compile-time. I've fiddled around with the hint library, trying to interpret the Template Haskell to get random HNats at run-time. This works, sort of, but there's no way to "liberate" the generated HNat because hint's `interpret` function requires a type witness. A look-alike string from the `eval` function is as close as you can get. Is there some dirty trick provided by the GHC API that would allow me to bind the generated HNat to a name and pass it around in a way similar to what GHCi seems to do? I realize that I probably have a grossly optimistic idea of what magic GHCi is performing when it interprets user input in a way that seems to allow this sort of thing. To summarize, I'm basically trying to wrap up the following process programmatically: ghci> n <- randomInt -- A random Int ghci> :load SomeModule.hs -- Contains `hNat` as above ghci> let hn = $(hNat n) -- Voila, a random HNat ghci> ... -- Do stuff with `hn`, then repeat Is something along the lines of what I'm imagining possible? If not, can I get close enough for my purposes? General insights and commentary are welcome as well. Regards, Eric

5 5

UHC-like JavaScript backend in GHC
by Jurriën Stutterheim 13 Nov '12

13 Nov '12

Hi all, Last year, I worked on improving the Utrecht Haskell Compiler (UHC) JavaScript backend[1] up to the point where it is now possible to write complete JavaScript applications with it. Alessandro Vermeulen then ported one of my web applications to the UHC JS backend, and we've started using the result of that in production afterwards. The result of these efforts were presented at IFL 2012 and HIW 2012 by Alessandro and Atze Dijkstra respectively. One of the most powerful new features of this backend, in addition to the customised RTS, is the small subset of JS we can use when importing JavaScript functions with the "js" calling convention. For example, we can import the push() method for arrays using (roughly) the following import declaration: foreign import js "%1.push(%2)" push :: JSArray a -> a -> IO (JSArray a) Here, we write a small expression in the import declaration, in which the object and arguments are numbered. The object argument, %1, corresponds to the `JSArray a` in the type signature of `push`, while the method argument %2 corresponds with the `a` in the type signature. Chris Done drew inspiration from this calling convention in designing the FFI for his Fay programming language[2]. One of UHC's nice features is that it is very easy to extend it, due to its heavy use of attribute grammars and its sophisticated variability management. Working on, and extending the UHC JavaScript backend was relatively easy because of this. One of UHC's downsides, however, is that it lags behind on supporting advanced language features, such as GADTs, functional dependencies, type families, etc. As a result, only a limited number of packages from Hackage can be compiled with UHC. In addition, some code requires additional workarounds and explicit type signatures, which would be redundant if, e.g., fundeps would be available. In an ideal situation, we can have both the js calling convention from UHC's JavaScript backend, and GHC's more advanced language support. Combined, we can use most libraries on Hackage, we don't have to worry about the lack of language support while designing our JS applications, and we don't have to use explicit type annotations in scenarios where, e.g. fundeps, would un-ambiguate the situation quite easily. In the near future (i.e. after I have finished my MSc thesis), I would like to get started with getting more familiar with GHC's internals. In particular, I would like to see if it is possible to implement the js calling convention in GHC and have GHC spit out JavaScript, much like UHC is currently doing. Before I get started: does the GHC architecture currently allow for adding a new calling convention which departs from the conventional C FFIs and introduces a custom RTS? If not, where are the current major bottlenecks? And would it be possible to remove these bottlenecks, without significantly affecting the compilation times, and without affecting the performance of generated native code (when the JS backend is not used)? Any input on this is appreciated :) Cheers, Jurriën [1] http://uu-computerscience.github.com/uhc-js/ [2] http://fay-lang.org

5 8

Where has the special built-in inline function gone?
by Johan Tibell 13 Nov '12

13 Nov '12

Hi all, For the first time, I wanted to use the special built-in inline function. To my dismay, I can't find it anywhere! Here's a minimal example: --8<--------- module Main where import GHC.Prim f x = x + 1 {-# INLINE f #-} g h x = inline h x main = print $ g f 1 --8<--------- $ ghc /tmp/Repro.hs [1 of 1] Compiling Main ( /tmp/Repro.hs, /tmp/Repro.o ) /tmp/Repro.hs:8:9: Not in scope: `inline' Perhaps you meant `unlines' (imported from Prelude) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 -- Johan

2 2

Using DeepSeq for exception ordering
by Simon Hengel 13 Nov '12

13 Nov '12

Hi, I'm puzzled whether it is feasible to use existing NFData instances for exception ordering. Here is some code that won't work: return $!! 'a' : throw exceptionA throwIO exceptionB Here GHC makes a non-deterministic choice between exceptionA and exceptionB. The reason is that the standard DeepSeq instances use `seq`, and `seq` does not help with exception ordering**. I tried several things (ghc-7.4.2 with -O2), and the following seems to order the exceptions for this particular case: (evaluate . force) ('a' : throw exceptionA) throwIO exceptionB But I'm a little bit worried that this may not hold in general, e.g. (return $!! 'a' : throw exceptionA) >>= evaluate throwIO exceptionB results in exceptionB. I think my main issue here is that I do not properly understand how seq and seq# (which is used by evaluate) do interact with each other. And how I can reason about code that uses both. The question is really whether it is "somehow" feasible to use existing NFData instances to order exceptions. Or would we need to define a separate type class + instances for that, e.g.: class DeepEvaluate a where deepEvaluate :: a -> IO a deepEvaluate = evaluate instance DeepEvaluate Char where instance DeepEvaluate a => DeepEvaluate [a] where deepEvaluate = mapM deepEvaluate If you have any related ideas or thoughts, I'd love to hear about them. Cheers, Simon ** This is desired behavior, see the discussion at http://hackage.haskell.org/trac/ghc/ticket/5129

6 12

Undocumented(?) magic "this" package-id in PackageImports
by Herbert Valerio Riedel 13 Nov '12

13 Nov '12

Hello Simon, I just found out that in combination with the PackageImports extension there's a special module name "this" which according to [1] always refers to the current package. But I couldn't find this rather useful feature mentioned in the GHC 7.6.1 Manual PackageImports section[2]. Has this been omitted on purpose from the documentation? Cheers, hvr [1]: https://github.com/ghc/ghc/commit/436a5fdbe0c9a466569abf1d501a6018aaa3e49e [2]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#p…

2 2

Building GHC for BB10 (QNX)
by Stephen Paul Weber 12 Nov '12

12 Nov '12

Hey all, I'm interesting in trying to get an initial port for BlackBerry 10 (QNX) going. It's a POSIXish environment with primary interest in two architechtures: x86 (for simulator) and ARMv7 (for devices). I'm wondering if <http://hackage.haskell.org/trac/ghc/wiki/Building/Porting> is fairly up-to-date or not? Is there a better place I should be looking? One big difference (which may turn out to be a problem) is that the readily-available QNX compilers (gcc ports) are cross-compilers. I realise that GHC has no good support to act as a cross-compiler yet, and anticipate complications arising from trying to build GHC using a cross-compiler for bootstrapping (since that implies GHC acting as a cross-compiler at some point in the bootstrapping). Any suggestions would be very welcome. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

2 1

How to use `trace` while debuging GHC
by Iavor Diatchki 12 Nov '12

12 Nov '12

Hello, While working on GHC sometimes I find it useful to dump the values of intermediate expressions, perhaps in the middle of pure code, using a combination of `trace` and `ppr`. The issue is that `ppr` returns an `SDoc`, and to turn an `SDoc` into a `String`, I need some `DynFlags`. There used to be a value called `tracingDynFlags` that I could use to dump values, but it has disappeared... Did it get moved somewhere, or is there a better way to get the same effect? -Iavor

4 3

Unexpected ambiguity in a seemingly valid Haskell 2010 program
by Roman Cheplyaka 11 Nov '12

11 Nov '12

For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman

4 7

Status of stack trace work
by Johan Tibell 08 Nov '12

08 Nov '12

Hi! I can't wait until we have some for of stack traces in GHC. What's the current status? Did the semantics you presented at HIW12 work out? Even though the full bells and whistles of full stack traces is something I'd really like to see, even their more impoverished cousins, the lexical stack trace, would be helpful in tracking down just which call to head gave rise to a "head: empty" list error. Once we do have some sort of stack traces, could we have throw automatically attach it to the exception, so we can get a printed stack trace upon crash? Is that how e.g. Java deals with that? Will that make other uses of exceptions (such as throwing async exceptions to kill threads) get much more expensive if we try to attach stack traces? A frequent user of async exceptions are web servers that start a timeout call per request. -- Johan

2 1