- Glasgow-haskell-users

Call for talks: Haskell Implementors Workshop 2013, Sept 22, Boston
by Ryan Newton 30 Jul '13

30 Jul '13

Please pass on this announcement! The deadline is in two weeks.* * * * * Call for Talks* ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2013 Boston, USA, September 22th, 2013 The workshop will be held in conjunction with ICFP 2013 http://www.icfpconference.org/icfp2013/ *Important dates* Proposal Deadline: *13th August 2013 (by midnight, any timezone)* Notification: 27th August 2013 Workshop: 22th September 2013 The Haskell Implementors' Workshop is to be held alongside ICFP 2013 this year in Boston. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This relatively new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2013. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for a relatively short talk. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 200 words. Submissions should be made via EasyChair. The website is: https://www.easychair.org/conferences/?conf=hiw2013 If you don't have an account you can create one here: https://www.easychair.org/account/signup.cgi Because the submission is an abstract only, please click the "abstract only" button when you make your submission. There is no need to attach a separate file. We will also have a lightning talks session which will be organised on the day. These talks will be 2-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Ryan Newton (Indiana University) * Neal Glew (Intel Labs) * Edward Yang (Stanford University) * Thomas Schilling (University of Kent) * Geoffrey Mainland (Drexel University)

1 0

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