- Haskell-Cafe - Haskell.org

ANNOUNCE: GHC version 7.10.2
by Ben Gamari 31 Jul '15

31 Jul '15

===================================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.10.2 ===================================================================== The GHC Team is pleased to announce a new bug-fix release of GHC, 7.10.2. There have been a number of significant bug fixes since the 7.10.1 (with over 70 defects fixed). These include fixes affecting type-checker correctness, runtime stability, and compiler performance. For this reason we highly recommend that users of 7.10.1 upgrade quickly. Note that due to changes made in this release to GHC's optimizer, previously fragile-but-working rewrite rules may fail to fire. One example of this was found in the widely-used `text` package late in the release cycle, which manifested in long compilation times and poor code generation for `Text` literals (see [Trac #10528]). Users are advised to use text >=1.2.1.2 which includes more robust rewrite rules. The full release notes including a complete listing of the changes in this release can be found here, https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-1… [Trac #10528]: https://ghc.haskell.org/trac/ghc/ticket/10528 How to get it ~~~~~~~~~~~~~ Both binary and source tarballs of GHC itself are available on the release download page, https://www.haskell.org/ghc/download_ghc_7_10_2 For a more smoother, better integrated experience users are encouraged to find a Haskell distribution. While these alternatives may not yet include 7.10.2, they offer tools and libraries to quickly get users up and running, as well as potentially better integration with the host operating system and package manager. See, https://www.haskell.org/downloads for more details. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below), https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms supported by GHC and the people responsible for them can be found here, https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ If you enjoy using GHC, you will likely also enjoy contributing to it! We are always looking for new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC developer site, https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ In https://downloads.haskell.org/~ghc/7.10.2/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key, Benjamin Gamari <ben(a)well-typed.com> Fingerprint: FFEB 7CE8 1E16 A36B 3E2D ED6F 2DE0 4D4E 97DB 64AD

6 10

ANN: hsqml-datamodel(-vinyl) = data model for QML
by Marcin Mrotek 29 Jul '15

29 Jul '15

Hello, I've just uploaded a package that enables using Haskell records in QML table- or listviews: http://hackage.haskell.org/package/hsqml-datamodel There's also an implementation for Vinyl: http://hackage.haskell.org/package/hsqml-datamodel-vinyl Best regards, Marcin Mrotek

2 1

haskell-src-exts maintenance
by Matthew Pickering 28 Jul '15

28 Jul '15

Dear List, There are a large number of untriaged pull requests and issues currently open on the issue tracker for haskell-src-exts. The tool is widely used by tool writers but the last commit to the project is now over 6 months ago. I think it is important to get this work merged and update the parser to support modern language features introduced in GHC 7.8 and 7.10. I would personally be capable of helping with this effort but before doing so I would appreciate a comment from the current maintainers as to the current status of the project. So, 1. Does anyone know if Niklas or Peter plan to return to the project? 2. Is there anyone else who is interested in updating the HSE parser? Matt

7 11

Names in a record changes read behavior?
by Mike Meyer 28 Jul '15

28 Jul '15

Ok, this all works as expected: λ> data Point = Point Float Float deriving (Show, Read) λ> Point 1.0 1.0 Point 1.0 1.0 λ> read "Point 1.0 1.0" *** Exception: Prelude.read: no parse λ> read "Point 1.0 1.0" :: Point Point 1.0 1.0 But now we add names to the values in the Point, and things change: λ> data Point = Point {x :: Float, y :: Float } deriving (Show, Read) λ> Point 1.0 1.0 Point {x = 1.0, y = 1.0} λ> read "Point 1.0 1.0" *** Exception: Prelude.read: no parse λ> read "Point 1.0 1.0" :: Point *** Exception: Prelude.read: no parse λ> read "Point {x = 1.0, y = 1.0 }" :: Point Point {x = 1.0, y = 1.0} OK, why won't read accept the same syntax as the REPL? I can see wanting Read and Show to be inverses of each other, though I think it's a bit misguided. But if we're going to be that strict about them being inverses, shouldn't we also insist that the READ eval print loop only accept what read will accept?

3 4

Re: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs
by wren romano 28 Jul '15

28 Jul '15

On Tue, Jul 7, 2015 at 3:35 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > If you post a repro case someone (even me) might help. The devil is always in the details. The smallest repro I can come up with (which is still related to the actual problem) is as follows. In case it matters for the solution, there are a number of important bits I've erased. Most importantly, the inferType function is actually mutually recursive with a checkType function, though that doesn't seem to be the cause of the problem. {-# LANGUAGE DataKinds, PolyKinds, GADTs #-} data Type = Fun Type Type data Sing :: Type -> * where SFun :: Sing i -> Sing j -> Sing (Fun i j) data AST :: (Type -> *) -> Type -> * where App :: ast (Fun a b) -> ast a -> AST ast b class ABT (abt :: Type -> *) where view :: abt a -> AST abt a unview :: AST abt a -> abt a class WellTypedABT (abt :: Type -> *) where unviewWT :: Sing a -> AST abt a -> abt a typeOf :: abt a -> Sing a data TypeCheckMonad a = TCM { unTCM :: a } instance Functor TypeCheckMonad where fmap f = TCM . f . unTCM instance Applicative TypeCheckMonad where pure = TCM TCM f <*> TCM x = TCM (f x) instance Monad TypeCheckMonad where return = pure TCM x >>= k = k x inferType :: (ABT abt, WellTypedABT abt') => abt a -> TypeCheckMonad (abt' a) inferType e0 = case view e0 of App e1 e2 -> do e1' <- inferType e1 case typeOf e1' of SFun typ2 typ3 -> do e2' <- inferType e2 return . unviewWT typ3 $ App e1' e2' -- Live well, ~wren

4 5

Munich Haskell Meeting, 2015-07-29 @ 19:30
by Christian Neukirchen 27 Jul '15

27 Jul '15

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, July 29 at Cafe Puck at 19h30. For details see here: http://www.haskell-munich.de/dates If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jul-2015/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

fun fact: value of truncate -Infinity depends on optimisation level
by Johannes Waldmann 26 Jul '15

26 Jul '15

Just for general amusement - I was debugging very strange behaviour in a straightforward deterministic program, where the output value seemed to depend on ghc's optimization level. Well, it turned out that I (accidentally) computed truncate (logBase 2 0) :: Int, and that's 0 with -O0, but -9223372036854775808 with -O2. https://github.com/jwaldmann/matchbox/issues/19

1 0

ANN: haddock-2.16.1
by Mateusz Kowalczyk 24 Jul '15

24 Jul '15

Hi, We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I inline the changelog at the bottom. It should work fine with 7.10.x GHC family. The packages are already on Hackage: haddock for the executable, haddock-api for the guts and use from Haskell and haddock-library which is the comment parser. It should also be shipping with GHC 7.10.2. I think two things are worth mentioning before: * The pending mathjax PR[1] is going to be included in future release of Haddock. As it is likely to break the interface file version, I am putting it off a bit to bundle with other possibly interface-breaking changes. * Our GSOC student has successfully completed first part of his project[2]. It involves native source code highlighting and perhaps more excitingly, source hyperlinking: you should now be able to click on identifiers to be taken to their definitions. This change is not in 2.16.1 as it is rather recent so we erred on the side of safety when picking what to release with GHC 7.10.2. You can try it by building current Haddock master, should work with 7.10.x family. As usual, if you want to contribute, please do so on GitHub. We're also on IRC under #haddock. Thanks! Changes in version 2.16.1 * Don't default to type constructors for out-of-scope names (#253 and #375) * Fix Hoogle display of constructors (#361) * Fully qualify names in Hoogle instances output (#263) * Output method documentation in Hoogle backend (#259) * Don't print instance safety information in Hoogle (#168) * Expand response files in arguments (#285) * Build the main executable with -threaded (#399) * Use SrcSpan of declarations for inferred type sigs (#207) * Fix cross-module instance locations (#383) * Fix alignment of Source link for instances in Firefox (#384) [1]: https://github.com/haskell/haddock/pull/397 [2]: https://github.com/haskell/haddock/pull/410 -- Mateusz K.

6 5

Re: [Haskell-cafe] Discussion: The CLOEXEC problem
by Donn Cave 24 Jul '15

24 Jul '15

Quoth David Turner <dave.c.turner(a)gmail.com>, ... > Non-inheritable-by-default makes sense to me - if you forget to clear > FD_CLOEXEC when you meant to then your program breaks loudly and obviously; This is where we differ. First, it isn't fair to say we "forget" to clear FD_CLOEXEC, if in pre-existing software we didn't have a CLOEXEC bit to clear. Rather, in the existing set of applications that have an exec - whether in Haskell code or not - we can expect that some subset of them will start to behave differently. Maybe behave better, but in any case likely a surprise to everyone because we've reversed the default on some large subset of file descriptors. And I think it's very optimistic to predict that the breakage will be obvious - the obvious effects will naturally be obvious, but I personally am not up to accounting for all non-obvious cases. And there's the other FDs - inherited, non-Haskell, sockets - so we still need another solution if we're serious about fixing the problem. Donn

1 0

Bibliographic references on advantages of functional languages for refactoring
by Nicola Gigante 23 Jul '15

23 Jul '15

Hi all, I’m writing my master thesis, which is not itself about functional programming but I use Haskell as the language chosen for the implementation of whatever I’m talking about. To motivate the choice more than “I like the language” I’m arguing that since I’m implementing experimental stuff and I’ll need to change the code and refactor very often, a strongly typed language is what I need. I wrote this sentence: "Strongly-typed programming eases the refactoring process by leveraging the compiler to spot wrong transformations before they turn into runtime bugs” Since this thesis is not itself about functional programming this sentence needs to be backed by something. In other words I need to cite some published paper where this is said/surveyed/proved/whatever. So the question: can you help me find referentiable published work relative to how strongly-typed functional programming eases refactoring? A survey or some case-study report or some functional pearl, dunno. Thank you very much in advance, Nicola

4 4