- Glasgow-haskell-users

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 26 Sep '14

26 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

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 24 Aug '14

24 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