Adam Gundry | 12 Sep 18:41 2014

Type checker plugins

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,
Merijn Verstraaten | 3 Sep 07:59 2014

GHC not able to detect impossible GADT pattern

I’ve been trying to stretch GHC’s type system again and somehow managed to get myself into a position
where GHC warns about a non-exhaustive pattern where adding the (according to GHC) missing pattern
results in a type error (as intended by me). It seems that even with closed type families GHC can’t infer
some patterns can never occur? Complete code to reproduce the issue is including below, the
non-exhaustive pattern happens in the local definitions ‘f’ of push and pull.

I’m open to suggestions for other approaches.

Kind regards,

{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE UndecidableInstances #-}
module Test where

import Data.Proxy
import GHC.Exts

data Message

data SocketType = Dealer | Push | Pull

data SocketOperation = Read | Write

(Continue reading)

Michael Snoyman | 25 Aug 12:25 2014

Document for review: evaluation order and state tokens

As part of trac ticket 9390[1], Simon PJ recommended that we try to get a document written that clarifies some of the issues regarding evaluation order, and get it included in the GHC wiki. After a few iterations with review from Simon, I've got a first "publicly consumable" version available at:

I'd appreciate any feedback on this document before I add it to the wiki.

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Adrian Victor Crisciu | 24 Aug 00:45 2014


After 3 days of frustrating trials and errors, I managed to install the new hmatrix package on Slackware 13.1. I post this message in case anyone else hits the same problem, as the process requires some alteration of the standard build process of ATLAS, LAPACK, hmatrix and hmatrix-gsl. The following steps assume that LAPACK is built against an optimized ATLAS library.

1.) By default, ATLAS builds only static libraries. However, hmatrix needs shared objects, so ATLAS should be configured with the --share option and, after the build is complete, the commands "make shared" and/ore "make ptshared" need to be issued in BUILDDIR/lib

2.) LAPACK also buils by default only static libraries and, for the same reason as above, we need position independent conde in ALL the objects in liblapack. In order to do this we need to
      2.1.) Add -fPIC to OPTS, NOOPT and LOADOPT in LAPACKROOT/
       2.2.) Change the BLASLIB macro in the same file to point to the optimized tatlas (os satlas) library
      2.3.) Add the target to SRC/Makefile:
              ../ $(ALLOBJ)
                        gfortran -shared -W1 -o $ <at> $(ALLOBJ)
3.) Change the extra-libraries line in hmatrix.cabal to read:
      extra-libraries: tatlas lapack

4.) Change the extra-library line in hmatrix-gsl to read:
       extra-libraries: gslcblas gsl

Again, this procedure worked for may Slackware 13.1 linux box, but I think it will work on any decent linux machine.

Thanks everyone for your time and useful comments!
Adrian Victor.

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Adrian Victor Crisciu | 21 Aug 14:26 2014

hmatrix- installation problem


I tried to upgrade from hmatrix to hmatrix- and both cabal install and cabal configure complained about missing blas and lapack libraries. However, I do have those libraries installed, and I passed their locations through --extra-include-dirs and --extra-lib-dirs with no results.

I use cabal, ghc 7.8.2 and gcc 4.4.4 on a Slackware-13.1 64-bit linux box.

Any idea of what is going wrong (and how to correct it?)


Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Wolfgang Jeltsch | 15 Aug 22:10 2014

Rules for class methods and Safe Haskell


the module Control.Arrow declares a set of rules for the Arrow class. It
is marked “Trustworthy”, probably to allow these rules to actually fire.

Now these rules are only correct for class instances that actually
satisfy the arrow laws. If the author of another module defines an
instance of Arrow that does not respect the laws, this other module
could still be considered “Safe” by GHC, although the rules from
Control.Arrow are bogus now.

Is this considered a problem?

All the best,

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Wolfgang Jeltsch | 15 Aug 22:04 2014

Are safe coercions safe in the sense of Safe Haskell?


I would expect the function

    coerce :: Coercible a b => a -> b

to be safe in the sense of Safe Haskell. However, the Data.Coerce module
is marked “Unsafe”. The coerce function is also available via GHC.Exts
and GHC.Prim. The former module is marked “Unsafe”, but the latter is
(surprisingly) marked “Safe-Inferred”.

What are the reasons behind this?

All the best,

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

'import ccall unsafe' and parallelism

Greetings everybody,

I happen to be a bit confused with regards to unsafe foreign imports and

Assume the following C function:

foreign import ccall unsafe "cfun"
  cfun :: CInt -> IO ()

Now, cfun does some work:

go xs = unsafePerformIO $ do
  forM_ xs $ cfun
  return $ somethingUnhealthy

And I'd like to parallelize this:

parMap rdeepseq go [costly,costly]

However, due to the way ghc handles unsafe imports, namely block
everything else whenever 'cfun' is called, I happen to have only one
active 'go'. Lets assume 'cfun' is cheap and would suffer from 'ccall
safe' more than I'd be willing to pay.

Is there any fix possible?

Viele Gruesse,

PS: The real problem happens to use a bunch of different judy arrays,
each of which lives in its on thread; 300 judy arrays, 300 threads, each
up to 20 million inserts. But I think the basic problem can be reduced
to "how to parallelize 'ccall unsafe's.
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Michael Jones | 13 Aug 06:44 2014

Odd FFI behavior

I have some strange behavior with GHC 7.6.3 on Ubuntu 14 TLS when using FFI and I am looking for some ideas on
what could be going on.

Fundamentally, adding wait calls (delays coded in the C) changes the behavior of the C, in that returned
status codes have proper values when there are delays, and return errors when there are no delays. But
these same calls result in proper behavior on the Aardvark’s serial bus, return proper data, etc. Only
the status get’s messed up.

The module calls a thin custom C layer over the Aaardvark C layer, which dynamically loads a dll and makes
calls into it. The thin layer just makes the use of c2hs eaiser.

It is always possible there is some kind of memory issue, but there is no pattern to the mishap. It is random.
Adding delays just changes probabilities of bad status.

I made a C version of my application calling the same custom C layer, and there are no problems. This sort of
indicates the problem is with the FFI.

Because the failures are not general in that they target one particular value, and seem to be affected by
time, it makes me wonder if there is some subtle Haskell run time issue. Like, could the garbage collector
be interacting with things?

Does anyone have an idea what kind of things to look for?


DLL loader

static void *_loadFunction (const char *name, int *result) {
    static DLL_HANDLE handle = 0;
    void * function = 0;

    /* Load the shared library if necessary */
    if (handle == 0) {
        u32 (*version) (void);
        u16 sw_version;
        u16 api_version_req;

        handle = dlopen(SO_NAME, RTLD_LAZY);
        if (handle == 0) {
            fprintf(stderr, "Unable to load %s\n", SO_NAME);
            fprintf(stderr, "%s\n", dlerror());
            *result = API_UNABLE_TO_LOAD_LIBRARY;
            return 0;

        version = (void *)dlsym(handle, "c_version");
        if (version == 0) {
            fprintf(stderr, "Unable to bind c_version() in %s\n",
            fprintf(stderr, "%s\n", dlerror());
            handle  = 0;
            *result = API_INCOMPATIBLE_LIBRARY;
            return 0;

        sw_version      = (u16)((version() >>  0) & 0xffff);
        api_version_req = (u16)((version() >> 16) & 0xffff);
        if (sw_version  < API_REQ_SW_VERSION ||
            API_HEADER_VERSION < api_version_req)
            fprintf(stderr, "\nIncompatible versions:\n");

            fprintf(stderr, "  Header version  = v%d.%02d  ",
                    (API_HEADER_VERSION >> 8) & 0xff, API_HEADER_VERSION & 0xff);

            if (sw_version < API_REQ_SW_VERSION)
                fprintf(stderr, "(requires library >= %d.%02d)\n",
                        (API_REQ_SW_VERSION >> 8) & 0xff,
                        API_REQ_SW_VERSION & 0xff);
                fprintf(stderr, "(library version OK)\n");

            fprintf(stderr, "  Library version = v%d.%02d  ",
                    (sw_version >> 8) & 0xff,
                    (sw_version >> 0) & 0xff);

            if (API_HEADER_VERSION < api_version_req)
                fprintf(stderr, "(requires header >= %d.%02d)\n",
                        (api_version_req >> 8) & 0xff,
                        (api_version_req >> 0) & 0xff);
                fprintf(stderr, "(header version OK)\n");
            handle  = 0;
            *result = API_INCOMPATIBLE_LIBRARY;
            return 0;

    /* Bind the requested function in the shared library */
    function = (void *)dlsym(handle, name);
    *result  = function ? API_OK : API_UNABLE_TO_LOAD_FUNCTION;
    return function;
cheater00 . | 6 Aug 16:18 2014

cabal repl failing silently on missing exposed-modules

I have just spent some time trying to figure out why all of a sudden
"cabal repl" silently exits without an error message. What helped was
to take a project that could launch the repl and compare the cabal
files to my new project. It turns out the exposed-modules entry was
missing. I was wondering whether this behaviour was intentional, as I
don't recollect this happening before, but I don't have older systems
to test this on.

The reason I wanted to run a repl without editing exposed modules was
to test some dependencies I pulled in to the sandbox with cabal
install. The package in question didn't have any code of its own yet.
In this case I would just expect ghci to load with the Prelude.

Volker Wysk | 5 Aug 18:41 2014

Old code broken by new Typeable class


I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my code, 

because the Typeable class has been changed. The compiler produces this 




    ‘typeOf’ is not a (visible) method of class ‘Typeable’


I want to define System.Posix.Process.ProcessStatus to be an instance of 

Typeable, so I can throw and catch it as an exception. ProcessStatus isn't 

typeable by default.

Is it still possible to make ProcessStatus a member of Typeable? How? 

Obviously, you can't accomplish it by deriving Typeable, because the definition 

can't be changed any longer.

This is the spot in question:


import System.Posix.Process

import Data.Typeable


data ProcessStatus = Exited ExitCode

                   | Terminated Signal

                   | Stopped Signal

                   deriving (Eq, Ord, Show)


instance Typeable ProcessStatus where

   typeOf = const tyCon_ProcessStatus

tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript"


                                           "Posix.ProcessStatus") []

instance Exception ProcessStatus




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