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:  http://www.haskell.org/ghc/reportabug"

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 https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rts/sm/Storage.c#L680

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> gmail.com> wrote:
yay :) 

On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki <iavor.diatchki <at> gmail.com> 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> well-typed.com> 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, http://www.well-typed.com/

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

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
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://git.haskell.org/ghc.git
$ ./sync-all -r git://git.haskell.org 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 ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk 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/package-data.mk] Error 1
make: *** [all] Error 2

And for G+, please use magiclouds#gmail.com.
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
Austin Seipp | 30 Sep 22:21 2014

The future of the haskell2010/haskell98 packages - AKA Trac #9590

Hello developers, users, friends,

I'd like you all to weigh in on something - a GHC bug report, that has
happened as a result of making Applicative a superclass of Monad:


The very condensed version is this: because haskell2010/haskell98
packages try to be fairly strictly conforming, they do not have
modules like Control.Applicative.

Unfortunately, due to the way these packages are structured, many
things are simply re-exported from base, like `Monad`. But
`Applicative` is not, and cannot be imported if you use -XHaskell2010
and the haskell2010 package.

The net result here is that haskell98/haskell2010 are hopelessly
broken in the current state: it's impossible to define an instance of
`Monad`, because you cannot define an instance of `Applicative`,
because you can't import it in the first place!

This leaves us in quite a pickle.

So I ask: Friends, what do you think we should do? I am particularly
interested in users/developers of current Haskell2010 packages - not
just code that may *be* standard Haskell - code that implies a
dependency on it.

There was a short discussion between me and Simon Marlow about this in
the morning, and again on IRC this morning between me, Duncan, Edward
K, and Herbert.

Basically, I only see one of two options:

 - We could make GHC support both: a version of `Monad` without
`Applicative`, and one with it. This creates some complication in the
desugarer, where GHC takes care of `do` syntax (and thus needs to be
aware of `Monad`'s definition and location). But it is, perhaps, quite

 - We change both packages to export `Applicative` and follow the API
changes in `base` accordingly.

Note that #1 above is contingent on three things:

 1) There is interest in this actually happening, and these separate
APIs being supported. If there is not significant interest in
maintaining this, it's unclear if we should go for it.

 2) It's not overly monstrously complex (I don't think it necessarily
will be, but it might be.)

 3) You can't like `haskell2010` packages and `base` packages together
in the general case, but, AFAIK, this wasn't the case before either.

I'd really appreciate your thoughts. This must be sorted out for 7.10
somehow; the current situation is hopelessly busted.



Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
Richard Eisenberg | 29 Sep 15:27 2014

Re: Permitting trailing commas for record syntax ADT declarations

To be fair, I'm not sure I like the make-commas-optional approach either. But, the solution occurred to me as possible, so I thought it was worth considering as we're exploring the design space.

And, yes, I was suggesting only to make them optional, not to require everyone remove them.


On Sep 26, 2014, at 5:34 PM, Brandon Allbery <allbery.b <at> gmail.com> wrote:

On Fri, Sep 26, 2014 at 5:21 PM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
I don't think that's necessarily is good style. I don't think we want two different ways of doing import lists.

Yes; I kinda hate the idea myself, it encourages an unreadable programming style. But it's not the wholesale breaking change you were suggesting, either.

brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org

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