September 2014 - Glasgow-haskell-users

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

13 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

Type checker plugins
by Adam Gundry 22 Oct '14

22 Oct '14

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: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker Feedback is very welcome, particularly if (a) you have an interesting use for this feature or (b) you think this is a terrible idea! Thanks, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 11

The future of the haskell2010/haskell98 packages - AKA Trac #9590
by Austin Seipp 14 Oct '14

14 Oct '14

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: https://ghc.haskell.org/trac/ghc/ticket/9590 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 doable. - 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. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 7

Aliasing current module qualifier
by Herbert Valerio Riedel 30 Sep '14

30 Sep '14

Hello *, Here's a situation I've encountered recently, which mades me wish to be able to define a local alias (in order to avoid CPP use). Consider the following stupid module: module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null ) where length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . AnnoyinglyLongModuleName.length Now it'd be great if I could do the following instead: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglyLongModuleName as M -- <- does not work length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . M.length However, if I try to compile this, GHC complains about AnnoyinglyLongModuleName.hs:4:1: Bad interface file: AnnoyinglyLongModuleName.hi AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) while GHCi tells me: Module imports form a cycle: module ‘AnnoyinglyLongModuleName’ (AnnoyinglyLongModuleName.hs) imports itself Is there some other way (without CPP) to create a local alias for the current module-name? If not, is there a reason GHC couldn't support this special case of self-aliasing the current module name? PS: Alternatively, this could be done as a language extension but that'd require extending the Haskell grammar: module AnnoyinglyLongModuleName as M (M.length, M.null) where Cheers, hvr

7 8

Re: Permitting trailing commas for record syntax ADT declarations
by John Wiegley 29 Sep '14

29 Sep '14

>>>>> Richard Eisenberg <eir(a)cis.upenn.edu> writes: > What if we just stopped requiring commas in import/export lists? As far as I > can tell, they're not necessary for proper parsing. +1 John

5 6

__GLASGOW_HASKELL__=708?
by Greg Fitzgerald 25 Sep '14

25 Sep '14

Using GHC 7.8.3 from the latest Haskell Platform on OS X 10.9.4, the __GLASGOW_HASKELL__ preprocessor symbol is being set to 708 instead of 783. I'd guess I have some stale files lying from previous versions GHC or HP, but I can't seem to find them. Any clues? $ cat wtf.hs {-# LANGUAGE CPP #-} $ ghc-7.8.3 -v -E wtf.hs 2>&1 | grep 708 /usr/bin/gcc -E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -I /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/base-4.7.0.1/include -I /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/integer-gmp-0.5.1.0/include -I /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/include '-D__GLASGOW_HASKELL__=708' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp wtf.hs -o /var/folders/w7/_cxvr2k540163p59kwvqlzrc0000gn/T/ghc14288_0/ghc14288_1.hscpp Thanks, Greg

2 2

Re: Preliminary proposal: Monoidal categories in base and proc notation support
by John Wiegley 15 Sep '14

15 Sep '14

>>>>> Sophie Taylor <sophie(a)traumapony.org> writes: > I am working on a proposal for some additions to the base library and some > modifications to GHC in the same style as the do notation support for > Applicatives. It is still very much a work in progress, but any input/ > constructive criticism would be greatly appreciated; this is the first one of > these I've written. Hi Sophie, The work you've proposed has an almost direct overlap with Edward Kmett's recent work in his "hask" library, so I'd prefer to see the dust settle out there to determine what the nicest interface could be. In particular Ed has discovered some nice expressions involving curried bifunctors that would be a shame to miss out on. As Simon said, this really should go to the libraries mailing list, where Edward is sure to weigh in. John

1 0

Re: win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux
by Mikolaj Konarski 12 Sep '14

12 Sep '14

(cross-com^H^H^Hposting to glasgow-haskell-users(a)haskell.org) Well, sorf-of. A few extra unobvious parameters and workarounds are required in each case, but it's doable, (arguably) simpler than real cross-compilation and already exhibits problems that real cross-compilation may in some circumstances face. Wiki pages (kudos to all previous authors): http://www.haskell.org/haskellwiki/GHC_under_Wine https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64 Examples of both kinds of binaries, for a project with gtk2hs and TH dependency: https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0 Please share your success reports here or on the wiki and let's exchange ideas, file concrete tickets and propose patches to make the two processes more accessible. Some tickets are mentioned in the wikis or can be traced from there, but there may be others I'm not aware of, so let's link them where appropriate. Hope this helps somebody, Mikolaj

1 0

Re: The list fusion lab
by John Wiegley 11 Sep '14

11 Sep '14

>>>>> David Feuer <david.feuer(a)gmail.com> writes: > Joachim Breitner wrote: >> Together with John Wiegly at ICFP, I started to create a list >> performance laboratory. You can find it at: >> https://github.com/nomeata/list-fusion-lab > Many thanks to you both! This sounds like an excellent idea. I do hope > someone figures out a way around the criterion dependency > shortly. It might also be nice to generalize it a bit to allow for analysis of other kinds of performance issues as well. I know that in pipes/conduit world, there's a lot of that happening right now, and a comprehensive comparative analysis there could be quite interesting as well. John

1 0

GHC not able to detect impossible GADT pattern
by Merijn Verstraaten 03 Sep '14

03 Sep '14

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, Merijn {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# 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 type family Restrict (a :: SocketOperation) (as :: [SocketOperation]) :: Constraint where Restrict a (a ': as) = () Restrict x (a ': as) = Restrict x as Restrict x '[] = ("Error!" ~ "Tried to apply a restricted type!") type family Implements (t :: SocketType) :: [SocketOperation] where Implements Dealer = ['Read, Write] Implements Push = '[Write] Implements Pull = '[ 'Read] data SockOp :: SocketType -> SocketOperation -> * where SRead :: SockOp sock 'Read SWrite :: SockOp sock Write data Socket :: SocketType -> * where Socket :: proxy sock -> (forall op . Restrict op (Implements sock) => SockOp sock op -> Operation op) -> Socket sock type family Operation (op :: SocketOperation) :: * where Operation 'Read = IO Message Operation Write = Message -> IO () class Restrict 'Read (Implements t) => Readable t where readSocket :: Socket t -> Operation 'Read readSocket (Socket _ f) = f (SRead :: SockOp t 'Read) instance Readable Dealer type family Writable (t :: SocketType) :: Constraint where Writable Dealer = () Writable Push = () dealer :: Socket Dealer dealer = Socket (Proxy :: Proxy Dealer) f where f :: Restrict op (Implements Dealer) => SockOp Dealer op -> Operation op f SRead = undefined f SWrite = undefined push :: Socket Push push = Socket (Proxy :: Proxy Push) f where f :: Restrict op (Implements Push) => SockOp Push op -> Operation op f SWrite = undefined pull :: Socket Pull pull = Socket (Proxy :: Proxy Pull) f where f :: Restrict op (Implements Pull) => SockOp Pull op -> Operation op f SRead = undefined foo :: IO Message foo = readSocket dealer

2 3