Barney Hilken | 25 Oct 15:53 2014

Recursion on TypeNats

If you define your own type level naturals by promoting

data Nat = Z | S Nat

you can define data families recursively, for example

data family Power :: Nat -> * -> *
data instance Power Z a = PowerZ
data instance Power (S n) a = PowerS a (Power n a)

But if you use the built-in type level Nat, I can find no way to do the same thing. You can define a closed type family

type family Power (n :: Nat) a where
	Power 0 a = ()
	Power n a = (a, Power (n-1) a)

but this isn't the same thing (and requires UndecidableInstances).

Have I missed something? The user guide page is pretty sparse, and not up to date anyway.

If not, are there plans to add a "Successor" constructor to Nat? I would have thought this was the main point
of using Nat rather than Int.

Yitzchak Gale | 22 Oct 14:50 2014

Re: GHC 7.4.2 on Ubuntu Trusty

I wrote:
>> How do I get a working GHC 7.4.2 on Trusty?

Thanks to all for the suggestions.

Daniel Trstenjak wrote, off-list:
> I can only recommend:

Thanks Daniel! I hadn't looked at Herbert's ppa for a while. Despite
the comments, which say it is only updated for precise but should
also work for trusty, the ppa actually *is* updated for trusty now.

This is trivially simple to use and worked great, so that's what I
ended up using.

But still - something really really needs to be done about GHC
portability. This thread makes it clear what a mess
we have inherited from the days when GHC was primarily a
research compiler. Let's face it - GHC is now also a serious
production compiler, and this urgently needs to be cleaned up.

Yitzchak Gale | 22 Oct 12:48 2014

GHC 7.4.2 on Ubuntu Trusty

In order support some older software that we released, we need
to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have
GHC 7.8.3.

The binary tarball for GHC 7.4.2 does not install on Trusty due to
multiple incompatibilities. For example, GHC requires GMP 3, but
Trusty only provides GMP >= 4. Etc.

I tried building GHC 7.4.2. from source on Trusty. But the process
won't boot from our currently installed GHC 7.8.3. The oldest
GHC binary I can get is GHC 7.6.3, which happens to be
still available from the Ubuntu distribution itself (neither the binary
tarball nor compiling from source work for GHC 7.6.3 on Trusty
either). But booting from GHC 7.6.3 won't work either.

How do I get a working GHC 7.4.2 on Trusty?

Evan Laforge | 22 Oct 02:02 2014

ghci balkiness on OS X?

On my OS X, if I load a couple hundred modules into ghci as bytecode,
text entry gets balky and laggy.  So e.g. if I hold down a key, the
letters will stream in but have frequent hiccups.  This seems to
adversely affect haskeline as well, such that, using vi mode,
sometimes ^[ to move to command mode will be lost, or it will
spontaneously go to insert mode, or ^[ followed by 'h' will be just
beep and remain in insert mode.  If I load most of the modules
compiled, this doesn't happen, or at least is not nearly so bad.

It doesn't seem to be due to background work by ghci or anything,
because it doesn't matter how long I wait after loading the modules.
My previous random guess was that increased memory use made the GC
work more, and my pauses were due to major collections.  But when I
try on linux, ghci remains responsive no matter how many modules I
load, so maybe it's an OS X only problem.

Do any other OS X users see this effect?
Jeremy | 20 Oct 14:53 2014

Dynamic only GHC

I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic
libraries (this is for a system where disc space is scarce). I'm using this

GhcRTSWays = thr
GhcLibWays = dyn
GhcDynamic = YES

Tried with and without GhcDynamic (asked on beginners how it's different to
DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end
of the build, then fails with:

  HC [stage 1] ghc/stage2/build/Main.dyn_o
  HC [stage 1] ghc/stage2/build/tmp/ghc-stage2
/usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3
collect2: error: ld returned 1 exit status
make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
make: *** [all] Error 2

If I build with only static libraries, everything seems to work OK.
Malcolm Gooding | 17 Oct 00:19 2014

Hiding import behaviour

With the prelude changes that people have been discussing recently
I've been wondering is there any reason why importing an identifier
explicitly and unqualified doesn't automatically hide any implicit
imports of the same identifier? Specifically I'm wondering about cases
where you've imported an identifier explicitly from only one module,
like this:

module Foo (x, ...) where { ... }
module Bar (x, ...) where { ... }

import Bar
import Foo (x)

Even if you needed a pragma to enable it I can't think of any sensible
reason why that shouldn't be equivalent to:

import Bar hiding (x)
import Foo (x)

I don't know much of GHC's internals, but it seems like a pretty
minimal change. Typing rules remain the same; explicit imports just
shadow implicits. So importing multiple identifiers both implicitly or
both explicitly would remain ambiguous.
Adam Gundry | 16 Oct 22:49 2014

Re: Type checker plugins

Thanks Simon, your branch does make it a lot more feasible to unflatten,
so I'll just go ahead and implement that in my plugin for now.

Eric, that's fair enough, and I don't have any concrete use cases for
non-equality constraints at the moment. I'm just keen to minimize the
restrictions placed on plugins, because it is much easier to recompile a
plugin than make changes in GHC itself!

On that note, I still wonder if it would be better to define TcPluginM
as a wrapper around TcS rather than TcM. While in principle TcM should
suffice, in practice GHC sometimes uses TcS for things that a plugin
might want (I've run into TcSMonad.matchFam, which could easily be
implemented in TcM instead). Is there any downside to defining a nice
API in TcPluginM but providing an escape hatch to TcS, not just TcM?



On 16/10/14 16:21, Eric Seidel wrote:
> Our branch is actually based on yours Simon, are there any changes in the past week that we should pull in for
people who want to experiment?
> Adam, we talked about passing other constraints to the plugins, but didn't have a concrete use-case at the
time, so we just kept it as simple as possible. I don't see a reason to hide constraints if, as you say, there
are plugins that may want to solve them. 
> Eric
> Sent from my iPhone
(Continue reading)

S. Doaitse Swierstra | 14 Oct 22:26 2014

status of rebindable syntax for arrows

The GHC manual already for quite a number of version states:

	• Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever arr, (>>>), first, app, (|||)
and loop functions are in scope. 
         But unlike the other constructs, the types of these functions must match the Prelude types very closely.
Details are in flux; if you want to use this, ask! 

When using this feature we get the error:

"Var/Type length mismatch: 
   [s{tv aVL} [tv]]
ghc: panic! (the 'impossible' happened)
 (GHC version 7.8.3 for x86_64-apple-darwin):
	tcTyVarDetails s{tv aVL} [tv]

Please report this as a GHC bug:"

So our question is whether we should really report this as a bug, and/or what we can do about this. 

Thanks for your help,

Bulat Ziganshin | 14 Oct 19:08 2014

optimizing StgPtr allocate (Capability *cap, W_ n)

Hello Glasgow-haskell-users,

i'm looking a the

if i correctly understand, it's speed-critical routine?

i think that it may be improved in this way:

StgPtr allocate (Capability *cap, W_ n)
    bdescr *bd;
    StgPtr p;


/// here starts new improved code:

    bd = cap->r.rCurrentAlloc;
    if (bd == NULL || bd->free + n > bd->end) {
        if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) {
        if (bd->free + n <= bd->start + BLOCK_SIZE_W)
            bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD)
            goto usual_alloc;

(Continue reading)

Iavor Diatchki | 13 Oct 22:34 2014

Re: Type checker plugins


We now have an implementation of type-checker with plugin support.   If you are interested in trying it out:

  - Checkout and build the `wip/tc-plugins` branch of GHC

  - As an example, I've extracted my work on using an SMT solver at the type level as a separate plugin:

   - To see how to invoke a module that uses a plugin, have a look in `examples/A.hs`.
     (Currently, the plugin assumes that you have `cvc4` installed and available in the path).

    - Besides this, we don't have much documentation yet.  For hackers: we tried to use `tcPlugin` on
    `TcPlugin` in the names of all things plugin related, so you could grep for this.  The basic API
     types and functions are defined in `TcRnTypes` and `TcRnMonad`.

Happy hacking,

On Mon, Oct 6, 2014 at 11:53 AM, Carter Schonwald <carter.schonwald <at>> wrote:
yay :) 

On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki <iavor.diatchki <at>> wrote:
Hi Adam,

I am back from vacation, and I think I should have some time to try to implement something along these lines. 


On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry <adam <at>> wrote:
Hi folks,

Those of you at HIW last week might have been subjected to my lightning
talk on plugins for the GHC type checker, which should allow us to
properly implement nifty features like units of measure or type-level
numbers without recompiling GHC. I've written up a wiki page summarising
the idea:

Feedback is very welcome, particularly if (a) you have an interesting
use for this feature or (b) you think this is a terrible idea!



Adam Gundry, Haskell Consultant
Well-Typed LLP,

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Magicloud Magiclouds | 13 Oct 03:03 2014

Dependencies missing when building ghc.


  I am with my new Ubuntu Trusty box. I have installed ghc by apt-get. Then I wanted to build ghc from git to upgrade to 7.8.3.

  I did following commands. I tried 'make clean', or reget the source. No luck yet.

$ git clone --recursive git://
$ ./sync-all -r git:// remote set-url origin
$ git checkout ghc-7.8.3-release
$ ./sync-all get
$ rm -r libraries/time # as prompted by sync-all
$ ./sync-all get
$ ./boot
$ ./configure
$ make
===--- building phase 0
make -r --no-print-directory -f phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f phase=1 phase_1_builds
"inplace/bin/ghc-cabal" check libraries/haskell98
"inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install "" --with-ghc="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-pkg"  --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --configure-option=CFLAGS=" -fno-stack-protector   " --configure-option=LDFLAGS="   " --configure-option=CPPFLAGS="   " --gcc-options=" -fno-stack-protector       " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="/usr/bin/ranlib" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy"
Configuring haskell98-
ghc-cabal: At least the following dependencies are missing:
base ==4.8.*
make[1]: *** [libraries/haskell98/dist-install/] Error 1
make: *** [all] Error 2

And for G+, please use
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>