August 2014 - Glasgow-haskell-users

Rules for class methods and Safe Haskell
by Wolfgang Jeltsch 14 Nov '14

14 Nov '14

Hi, 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, Wolfgang

2 2

Document for review: evaluation order and state tokens
by Michael Snoyman 26 Aug '14

26 Aug '14

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: https://www.fpcomplete.com/user/snoyberg/general-haskell/advanced/evaluatio… I'd appreciate any feedback on this document before I add it to the wiki. Michael [1] https://ghc.haskell.org/trac/ghc/ticket/9390

2 2

hmatrix
by Adrian Victor Crisciu 25 Aug '14

25 Aug '14

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/make.inc 2.2.) Change the BLASLIB macro in the same file to point to the optimized tatlas (os satlas) library 2.3.) Add the target liblapack.so to SRC/Makefile: ../liblapack.so: $(ALLOBJ) gfortran -shared -W1 -o $@ $(ALLOBJ) (This step is a corected version of http://theoryno3.blogspot.ro/2010/12/compiling-lapack-as-shared-library-in.… ) 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.

2 1

PROPOSAL: Literate haskell and module file names
by Merijn Verstraaten 23 Aug '14

23 Aug '14

Ola! I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. Pros: - Tool authors can more easily determine non-haskell content of literate haskell files - Currently valid module names will not break - Report doesn't specify behaviour, so GHC can do whatever it likes Cons: - Someone has to implement it - ?? Discussion: 4 weeks Cheers, Merijn

10 17

hmatrix-0.16.0.4 installation problem
by Adrian Victor Crisciu 22 Aug '14

22 Aug '14

Hi, I tried to upgrade from hmatrix 0.15.2.1 to hmatrix-0.16.0.4 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 1.20.0.3, 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?) Thanks, Adrian-Victor.

5 9

Are safe coercions safe in the sense of Safe Haskell?
by Wolfgang Jeltsch 18 Aug '14

18 Aug '14

Hi, 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, Wolfgang

2 4

'import ccall unsafe' and parallelism
by Christian Höner zu Siederdissen 15 Aug '14

15 Aug '14

Greetings everybody, I happen to be a bit confused with regards to unsafe foreign imports and parallelism. 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, Christian 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.

6 9

Odd FFI behavior
by Michael Jones 14 Aug '14

14 Aug '14

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? Mike 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; _setSearchPath(); handle = dlopen(SO_NAME, RTLD_LAZY); if (handle == 0) { #if API_DEBUG fprintf(stderr, "Unable to load %s\n", SO_NAME); fprintf(stderr, "%s\n", dlerror()); #endif *result = API_UNABLE_TO_LOAD_LIBRARY; return 0; } version = (void *)dlsym(handle, "c_version"); if (version == 0) { #if API_DEBUG fprintf(stderr, "Unable to bind c_version() in %s\n", SO_NAME); fprintf(stderr, "%s\n", dlerror()); #endif 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) { #if API_DEBUG 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); else 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); else fprintf(stderr, "(header version OK)\n"); #endif 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; }

2 4

Overlapping and incoherent instances
by Simon Peyton Jones 12 Aug '14

12 Aug '14

Friends One of GHC's more widely-used features is overlapping (and sometimes incoherent) instances. The user-manual documentation is here<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio…>. The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively. However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time. Using LANGUAGE OverlappingInstances simply sets the "I am an overlapping instance" flag for every instance declaration in that module. This is a Big Hammer. It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping. It brutally applies to every instance in the module. Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped. The clue might be in the command line that compiles that module! Iavor has recently implemented per-instance-declaration pragmas, so you can say instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... instance {-# OVERLAPPING #-} Show [Char] where ... This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration). This new feature will be in GHC 7.10 and I'm sure you will be happy about that. But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer. The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle. We could make that two cycles if it was helpful. However, if you want deprecation-free libraries, it will entail a wave of library updates. This email is just to warn you, and to let you yell if you think this is a bad idea. It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely - it just seems wrong not to actively push authors in the right direction. These deprecations of course popped up in the test suite, so I've been replacing them with per-instance pragmas there too. Interestingly in some cases, when looking for which instances needed the pragmas, I found...none. So OverlappingInstances was entirely unnecessary. Maybe library authors will find that too! Simon

9 10

Re: Overlapping and incoherent and intentionally omitted instances
by Iavor Diatchki 11 Aug '14

11 Aug '14

Hello, Such a pragma sounds useful, and is very much like the "fails" instance from the "Instance chains" paper. You may also be interested in ticket #9334 (https://ghc.haskell.org/trac/ghc/ticket/9334) which proposes an alternative to overlapping instances, and I just updated it to point to #7775. -Iavor On Sun, Aug 10, 2014 at 7:19 AM, Henning Thielemann < schlepptop(a)henning-thielemann.de> wrote: > Am 29.07.2014 um 12:02 schrieb Johan Tibell: > > P.S. For e.g. INLINABLE we require that you mention the function name >> next to the pragma (which means that you can e.g. put the pragma after >> the declaration). What's the rationale to not require >> >> {-# OVERLAPPING Show [Char] #-} >> >> here? Perhaps it's too annoying to have to repeat the types? >> > > Once I proposed a pragma for documenting intentionally unimplemented > instances. In this case there is no instance you can write a pragma in > front of. Your OVERLAPPING syntax would be conform with the one of > NOINSTANCE: > > https://ghc.haskell.org/trac/ghc/ticket/7775 > > Maybe NOINSTANCE can be reconsidered in the course of the introduction of > the OVERLAP pragma? > >

1 0