- Haskell-Cafe - Haskell.org

GHC profiling overhead
by Kolář Dušan 25 Feb '20

25 Feb '20

Dear Café, I'm quite curious about overhead of the profiler... I've compiled my program with --make -threaded -rtsopts -O2 -prof options. It was started with +RTS -N5 -p Usually, the program evaluates like 6-7 hours of real time. What is the overhead of the profiling? After 8 hours of working, the program has not finished yet. I've looked over the Internet and it seems like the overhead may be 25 times slowdown and even worse. Is it true? If yes, it's not worth waiting then :-) Best regards, Dusan

3 2

[ANNOUNCE] GHC 8.8.2 is now available
by Ben Gamari 25 Feb '20

25 Feb '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.2. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.2 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.1: - A bug (#17088) in the compacting garbage collector resulting in segmentations faults under specific circumstances. Note that this may affect user programs even if they did not explicitly request the compacting GC (using the -c RTS flag) since GHC may fallback to compacting collection during times of high memory pressure. - A code generation bug (#17334) resulting in GHC panics has been fixed. - A bug in the `process` library causing builds using `hsc2hs` to fail non-deterministically on Windows has been fixed (Trac #17480) - A typechecker bug (#12088) resulting in programs being unexpectedly rejected has been fixed. - A bug in the implementation of compact normal forms resulting in segmentation faults in some uses (#17044) has been fixed. - A bug causing GHC to incorrectly complain about incompatible LLVM versions when using LLVM 7.0.1 has been fixed (#16990). As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.2/docs/html/users_guide/8.8.2-notes.h…

2 3

Lecturer, Senior Lecturer or Associate Professor in Programming Languages: University of Bristol
by Steven Ramsay 23 Feb '20

23 Feb '20

The University of Bristol are seeking to appoint an assistant/associate professor in Programming Languages, those with expertise in functional programming especially welcome! (Postdoc and funded PhD positions also available). Position: Lecturer, Senior Lecturer or Associate Professor in Programming Languages Location: University of Bristol, UK Type: Full time, open-ended contract Salary: £38,017 -- £59,135 per annum Applications deadline: March 11 Website: http://www.bristol.ac.uk/jobs/find/details.html?nPostingId=65334&nPostingTa… The Department of Computer Science at the University of Bristol is seeking to appoint a full-time faculty member in Programming Languages at Lecturer, Senior Lecturer or Associate Professor level; comparable to Assistant / Associate Professorship. You will be expected to both deliver outstanding teaching and undertake internationally leading research in the area of Programming Languages. There is opportunity to play a significant role in shaping and leading a new Programming Languages research group. The Department of Computer Science is an international centre of excellence in the foundations and applications of computing, ranked 4th in the UK for research intensity by the 2014 REF. The Department is already home to expertise in functional programming, program analysis, algorithms and complexity; it benefits from a close association with neighbouring groups in Cryptography and Trustworthy Systems. The University of Bristol is a leading institution among the UK's Russell Group Universities and is regularly placed among the top-ranking institutions in global league tables. Bristol is a friendly, green, coastal city with a rich and lively cultural scene and has consistently been voted one of the best places to live in the UK. This post is being offered on a full-time, open-ended contract. A recruitment supplement scheme is available up to £5K. For informal discussion about the post you are welcome to contact: Seth Bullock (Head of Department, mailto:seth.bullock@bristol.ac.uk) or Steven Ramsay (Lecturer in Programming Languages, mailto:steven.ramsay@bristol.ac.uk). The closing date for all applications is 23:59 on Wednesday 11 March 2020. Interviews are expected to take place shortly after the closing date.

1 0

A static analyzer
by Eirik Ravnskog 23 Feb '20

23 Feb '20

3 2

Munich Haskell Meeting, 2020-02-25 @ 19:30
by Leah Neukirchen 22 Feb '20

22 Feb '20

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tueday, February 25 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html 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-feb-2020/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 1

[Ann] base16, base16-lens, base32, base32-lens
by Emily Pillmore 18 Feb '20

18 Feb '20

Hi Everyone, It's been a productive weekend. I'm pleased to announce the following packages: * https://hackage.haskell.org/package/base16 * https://hackage.haskell.org/package/base16-lens * https://hackage.haskell.org/package/base32 * https://hackage.haskell.org/package/base32-lens These libraries are the conclusion of a small audit I've been doing of the existing base encoding implementations, focusing on performance and providing a common interface for both ByteString and Text values. As always, these libraries have a pretty obvious optical interface, and that has been provided as well. Cheers, and happy President's Day weekend! - Emily Pillmore

1 0

Seeking help with polysemy interpreter ..
by Debasish Ghosh 17 Feb '20

17 Feb '20

Hello - I have a typeclass like this .. class (Monad m) => DB m where query :: Text -> m (Maybe Account) ... and an instance that uses persistent and sqlite .. instance (MonadIO m) => DB (SqlPersistT m) where query ano = get (AccountKey ano) .. Now I want to move this to using an effect system - Polysemy .. data DB m a where Query :: Text -> DB m (Maybe Account) ... makeSem ''DB which generates the functions .. I need some help figuring out the type of the function that interpretes the above .. An initial intuition is this .. runDB :: Member SqlPersistT r => Sem (DB ': r) a -> Sem r a runDB = interpret $ \case Query ano -> get (AccountKey ano) which doesn't compile .. errors out with .. Couldn't match type ‘Control.Monad.Trans.Reader.ReaderT backend0 m0 (Maybe Account)’ with ‘Sem r (Maybe Account)’ Expected type: Sem r x Actual type: Control.Monad.Trans.Reader.ReaderT backend0 m0 (Maybe Account) • In the expression: get (AccountKey accountNo) I think I am missing something here. The type of interpret is shown as interpret :: (forall x (m :: * -> *). DB m x -> Sem r x) -> Sem (DB : r) a -> Sem r a But how do I translate the SqlPersistT part ? Any help will be appreciated. regards. -- Debasish Ghosh http://manning.com/ghosh2 http://manning.com/ghosh Twttr: @debasishg Blog: http://debasishg.blogspot.com Code: http://github.com/debasishg

2 2

(Feeling that) GHCi is trying to protect me from myself with overlapping instances and existential types
by Juan Casanova 16 Feb '20

16 Feb '20

Hello all, This stems from a Stack Overflow question that I posted a few days ago: https://stackoverflow.com/questions/60199424/overlapping-multi-parameter-in… I'd like to hear either agreement or a more convincing argument as to why GHCi behaves the way it does in this case, since the ones at Stack Overflow basically told me that it does to "protect me from being too dumb and not understanding my own code", the way I interpret it. I felt that was totally against the principles of Haskell, so I thought there must be more. I'm going to focus on my second example (on my own answer to the question) for the sake of clarity here. Consider the following code: {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ExistentialQuantification #-} module ExistentialTest where class Class1 a b where foo :: a -> b instance {-# INCOHERENT #-} Monoid a => Class1 a (Either b a) where foo x = Right (x <> x) instance {-# INCOHERENT #-} Monoid a => Class1 a (Either a b) where foo x = Left x data Bar a = Dir a | forall b. Class1 b a => FromB b getA :: Bar a -> a getA (Dir a) = a getA (FromB b) = foo b createBar :: Bar (Either String t) createBar = FromB "abc" createBar2 :: Bar (Either t String) createBar2 = FromB "def" This code compiles, but only because of the INCOHERENT annotations. If you remove those, it will give overlapping instances errors on both createBar and createBar2. I argue that those errors are senseless, because, while if t were instantiated to String then those instances would be valid, the functions createBar and createBar2 are by definition polymorphic, and the only way to make those functions work for every t is to use specifically one of the instances on each case. Therefore, the compiler should realize this, use that instance, and not complain about it. When using the INCOHERENT annotations it works, and uses the right instance on each case (because of course it would, the other instance is absolutely unusable in each of the cases). The best argument that I was given on stack overflow is that allowing that would make it confusing because people might use those polymorphic functions with the specific t ~ String instantiation of the types and expect the behaviour to use the instance that is not usable in general. I find that a really poor argument. A user of the function need not know in general how a function internally works (that it uses the Class1 instance, which is not a constraint on the function signature), and it would be way too much for a user of the function to look at that code (that they should not need to look at), and then guess which instance it might be using, and guess wrong. Having GHCi protect me from that highly hypothetical situation while preventing me from compiling theoretically correct programs seems strange at best. I have tried to think of potential situations where a similar kind of ambiguity might affect the actual type checking and not just what the user might (wrongly) think of it, but I haven't found any. From what I understand, though, the INCOHERENT annotation is dangerous in that if there were other instances which in fact did match in general, then GHCi would choose an arbitrary one. Therefore, I'd like them out of my code. Are there any comments on this that give me a more theoretical reason as to why Haskell disallows this without the INCOHERENT annotations? Is it worth proposing a change to the compiler to allow this? It basically seems that the compiler is checking the overlapping instances "too soon" before realizing that t cannot be unified with String within createBar, because it is a forall quantified polymorphic function. A way to see this is to precisely comment one of the instances and realize that you still get one error on each function, and on the one you removed the right instance for, it will actually say that there is no instance at all. It feels wrong that Haskell can tell you there are two instances that would match, and when you remove one of them, it tells you that there are no instances that match. That in of itself screams bug to me until someone gives me a really convincing explanation of why that is okay. Thanks once again for any time you spent on this, haskell-cafe. Juan Casanova. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

4 11

Re: [Haskell-cafe] (Feeling that) GHCi is trying to protect me from myself with overlapping instances and existential types
by Olaf Klinke 16 Feb '20

16 Feb '20

> the ones at Stack > Overflow basically told me that it does to "protect me from being too > dumb and not understanding my own code", the way I interpret it. I > felt that was totally against the principles of Haskell On the contrary! Protecing me against writing dumb code is one of the things where Haskell shines, and I am infinitely grateful for that. > Having GHCi protect me from that highly hypothetical situation while > preventing me from compiling theoretically correct programs seems > strange at best. But those theoretically correct programs may suddenly cease to be correct in very mysterious and little hypothetical ways, as explained below. I agree with Arien. Making the semantics of a function dependent on how many type class instances are in scope is totally against the principles of Haskell, IMHO. Even worse the function signature of createBar does not mention Class1 so at first glance there is no hint that type classes are at work here. Type class instances are hard to contain, in the sense that there is currently no mechanism of selectively importing or not importing them from some module. Change in semantics through orphan instances would be a nightmare to debug: Suppose you have written a package that defines Class1 and only the first incoherent instance. Alice comes along and uses your package to define a function useFoo :: Monoid a => a -> Either a a useFoo = foo and henceforth Alice relies on the semantics useFoo a = Right (a <> a), because that's what your package intends. Alice's code also depends on a package written by Bob, but she only uses some part of that package which is totally unrelated to useFoo and Class1. In an update of his package, Bob defines your second Class1 instance as orphan instance. Alice never explicitly imported any Class1 stuff from Bob's module, but the new instance will leak anyways. Suddenly the semantics of Alice's function changes, she gets useFoo a = Left a without any changes in her own code! If Bob did not adhere to the versioning policy then Alice has little chance of knowing that Bob's package is the cause. The only hint for Alice is the INCOHERENT pragma that signals danger, and you propose to take that away. Olaf

2 1

[ANN] zsh-haskell
by Marcin Szamotulski 16 Feb '20

16 Feb '20

Dear fellow Haskellers, I am pleased to announce a `zsh` completion for `cabal`, `ghc` and `ghc-pkg`. https://github.com/coot/zsh-haskell Cheers, Marcin Szamotulski

1 0