- Glasgow-haskell-users

GHC and GSL
by Adrian Victor Crisciu 29 Jul '13

29 Jul '13

Hi, I need to import in one of my programs the minimization module form Numeric.GSL.Minimization. When I run even the example code in interactive mode, ghci crashes with a "Bus error" message. Is this a bug, or is something wrong with my code? The offending program follows: module MinMaxTest where import Numeric.GSL.Minimization objFunc :: [Double] -> Double objFunc [x, y] = 10 * (x-1)^2 + 20 * (y-2)^2 + 30 main :: IO () main = do let (s, p) = minimize NMSimplex2 1e-2 30 [1, 1] objFunc [5, 7] print s print p I use ghc-7.6.3 on a Slackware-Linux platform. Can anyone help? Thank you in advance. Adrian-Victor

5 6

change location of user's package directory
by harry 28 Jul '13

28 Jul '13

How can I change the location that ghc and ghc-pkg use for the user's package directory? I'm running GHC in a very restricted environment where I don't have access to $HOME, but I can use specific subdirectories. -- View this message in context: http://haskell.1045720.n5.nabble.com/change-location-of-user-s-package-dire… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

3 4

Installing GHC and libgmp.so
by harry 24 Jul '13

24 Jul '13

I've had a lot of trouble installing the pre-build binary of GHC on various Linux systems for which packages don't exist - all of this stems from GHC looking for libgmp.so, instead of libgmp.so.3. Various combinations of --with-gmp-libraries haven't helped, particularly as I need a packaged build for copying onto shared machines where I don't have enough disk space to install from the binary package locally, and don't have root access to create a shortcut in /usr/lib64. Is it possible for someone to recompile the pre-build binaries, linked against a specific version of libgmp, instead of a default which happens to be on their machine? Or is there some other solution to my predicament? -- View this message in context: http://haskell.1045720.n5.nabble.com/Installing-GHC-and-libgmp-so-tp5733330… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

3 7

GHC and GSL
by Adrian Victor Crisciu 22 Jul '13

22 Jul '13

That's exactly what happened. Indeed, I work on a 64-bit platform, and the above program works flawlessly in compiled mode (stand-alone executable). It's a bit annoying, because I have to tinker a bit with each module in order to test it, but it works. Any idea what happens with ghci/64-bit? Thank you so much! Adrian-Victor.

1 0

ANNOUNCE: ghci-ng package
by Herbert Valerio Riedel 20 Jul '13

20 Jul '13

Hello GHC HQ, I wanted to inform you that I created the `ghci-ng` package http://hackage.haskell.org/package/ghci-ng-7.6.3.3 which essentially is the ghc/* folder from the GHC source-tree with a ghci-ng.cabal file put in place (and some dummy .h files) to make the interactive-mode GHC front-end compilable w/o requiring the full GHC source-tree. The reason I created ghci-ng was to be able to backport features from GHC HEAD so that Haskell user not living on the bleeding edge (such as Haskell Platform users) don't have to wait for half a year or so till they can use new features[1]. On the other hand, this might also allow to expose new work-in-progress features to users in production environments to play with before those features find their way into a final GHC release, and thus help with developing new GHCi features in a more "agile" way by getting feedback from potential users earlier. So ghci-ng is *not* supposed to replace ghci, but rather provide an testing ground for evaluating new/experimental features which may get merged into upstream GHCi eventually if they prove useful. Please let me know what you think of this. [1]: The killer-feature right now being the new `:complete` command which allows the latest (unreleased) haskell-mode to provide REPL-completion from within the Emacs buffer. Cheers, hvr

1 0

How to fix DatatypeContexts?
by harry 19 Jul '13

19 Jul '13

data Eq a => Pair a = Pair {x::a, y::a} equal :: Pair a -> Bool equal pair = (x pair) == (y pair) This code will fail to compile, even with the deprecated DatatypeContexts extension, because equal must be given the Eq a => constraint, even though this has already been declared on the Pair type. Some of my code is littered with such redundant type constraints (although some of them could be replaced with a redundant pattern match). A proposal to enhance DatatypeContexts (#8026) in this way was rejected as unsound, as some nefarious uses of undefined would break the type system. Is there any way that the type system could be enhanced to avoid this redundancy? -- View this message in context: http://haskell.1045720.n5.nabble.com/How-to-fix-DatatypeContexts-tp5733103.… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

8 15

Overloaded record fields
by Adam Gundry 18 Jul '13

18 Jul '13

Hi everyone, I am implementing an overloaded record fields extension for GHC as a GSoC project. Thanks to all those who gave their feedback on the original proposal! I've started to document the plan on the GHC wiki: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan If you have any comments on the proposed changes, or anything is unclear about the design, I'd like to hear from you. Thanks, Adam Gundry

19 40

implicit params in instance contexts
by Ganesh Sittampalam 16 Jul '13

16 Jul '13

Hi, It seems that from GHC 7.4, the prohibition on implicit parameter constraints in instance declarations has been relaxed. The program below gives the error "Illegal constraint ?fooRev::Bool" in GHC 7.2.1 but loads fine in GHC 7.4.2 and GHC 7.6.2. I can't spot anything about this in the release notes, and the documentation (http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type-extension…) still says "You can't have an implicit parameter in the context of a class or instance declaration." So I wonder if this happened by accident, perhaps as part of the ConstraintKinds work or similar? I've wanted this feature a few times so if it's going to stay I might start using it. However it is a bit dangerous, so if it was added by accident it might warrant some discussion before deciding to keep it. For example as the value "set2" below shows, it can be used to violate datatype invariants. Cheers, Ganesh {-# LANGUAGE ImplicitParams #-} module Ord where import Data.Set ( Set ) import qualified Data.Set as Set newtype Foo = Foo Int deriving (Eq, Show) instance (?fooRev :: Bool) => Ord Foo where Foo a `compare` Foo b = if ?fooRev then b `compare` a else a `compare` b set1 = let ?fooRev = False in Set.fromList [Foo 1, Foo 3] set2 = let ?fooRev = True in Set.insert (Foo 2) set1 -- Ord> set2 -- fromList [Foo 2,Foo 1,Foo 3]

4 3

A possible alternative to dot notation for record access
by Judah Jacobson 12 Jul '13

12 Jul '13

Hi all, I had a quick idea about record field syntax as specified in the GSoC project plan: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan . Instead of "f.x" (to access field x of record f), maybe we could write "f{x}" as the record selection. That is, we'd reuse the brace notation which is already in place for record updates. Unlike dot notation, this is unambiguous and doesn't conflict with any existing syntax (AFAIK). It would also generalize to "f{x}{y}{z}" instead of "f.x.y.z". This proposal would add two new forms of expressions: f{x} to access field x of data f ({x}) = \f -> f{x} as a field access section Additionally, it seems like record mutation expressions could also have sections: ({x=2}) = \f -> f{x=2} That actually seems useful by itself, regardless of whether we use dot notation for field access. Best, -Judah

10 10

executable stack flag
by Jens Petersen 09 Jul '13

09 Jul '13

Hi, We noticed [1] in Fedora that ghc (7.4 and 7.6) are linking executables (again [2]) with the executable stack flag set. I haven't starting looking at the ghc code yet but wanted to ask first if it is intentional/necessary? (ghc-7.0 doesn't seem to do this.) Having the flag set is considered a bit of a security risk so it would be better if all generated executable did not have it set. I did some very basic testing of various executables, clearing their flags [3] and they all seemed to run ok without the executable stack flag set but I can't claim to have tested very exhaustively. (I thought perhaps it might be related to TemplateHaskell for example but even those executables seem to work, though I am sure I have not exercised all the code paths.) Does someone know the current status of this? Will anything break if the flag is not set? Is it easy to patch ghc to not set the flag? Does it only affect the NCG backend? Thanks, Jens [1] https://bugzilla.redhat.com/show_bug.cgi?id=973512 [2] http://ghc.haskell.org/trac/ghc/ticket/703 [3] using "execstack -c"

2 2