- Haskell-Cafe - Haskell.org

ANN: hledger 1.16
by Simon Michael 02 Mar '20

02 Mar '20

I'm pleased to announce hledger 1.17 ! hledger is a robust, cross-platform, plain text accounting tool, with command-line, terminal and web UIs. It is a modern and largely compatible reimplementation of Ledger CLI with many improvements. You can use it to track time, money, investents, cryptocurrencies, inventory and more. See: http://hledger.org http://plaintextaccounting.org hledger 1.17 is released on schedule on 2020-03-01. Thanks to release contributors Aleksandar Dimitrov, Brian Wignall, Stephen Morgan, Jacek Generowicz, Gaith Hallak, Eric Mertens, Jakob Schöttl, Carl Richard Theodor Schneider, David Zhang, Amarandus, Evilham, Mateus Furquim, and Rui Chen. HIGHLIGHTS: CSV single-field matching, easier SSV/TSV conversion, fixed/enhanced close command, undo in add command, more JSON output, org headline support in timedot format, GHC 8.10 support. See all changes at https://hledger.org/release-notes . GETTING STARTED: Many install methods are described at http://hledger.org/download. Here are three ways to build from source: stack update; stack install --resolver=lts hledger-lib-1.17 hledger-1.17 hledger-ui-1.17 hledger-web-1.17 --silent or: cabal v2-update; cabal v2-install hledger-1.17 hledger-web-1.17 hledger-ui-1.17 or: curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… less hledger-install.sh bash hledger-install.sh While building, peruse https://hledger.org/start For help, see http://hledger.org#help-feedback and join us on Freenode (#hledger, http://irc.hledger.org) or via Matrix (#freenode_#hledger:matrix.org, http://riot.hledger.org) New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon

1 1

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.8.3 is now available
by Ben Gamari 29 Feb '20

29 Feb '20

Ben Gamari <ben(a)well-typed.com> writes: > --text follows this line-- > <#part sign=pgpmime> > > Hello everyone, > > The GHC team is proud to announce the release of GHC 8.8.3. The source > distribution, binary distributions, and documentation are available at > > https://downloads.haskell.org/~ghc/8.8.3 > > Release notes are also available [1]. > Unfortunately there has been a slight mix-up in the binary distributions associated with this release and I will need to do a re-spin. I have pulled down the binary distributions for the time being. They should be back in a few hours. Many apologies for the confusion! Cheers, - Ben

2 2

How to deal with HTML input select option on a form using in a scotty and Text.Blaze.Html5
by Tebogo Sikwane 27 Feb '20

27 Feb '20

I am using scotty and Text.Blaze.Html5 Text.Digestive Text.Digestive.Blaze.Html5 What I want to achieve is a list of options as shown below. I have a Option sum type and will like to restrict the user to those options. data Options = Option1 | Option2 | Option3 | Option4 deriving Show Below is the Register record typeY data Register = Register { regName::Text , regOption::Options } deriving (Show,Eq) My problem is with Text.Digestive.choice. I don't know how to use it with Text.Digestive.Blaze.Html5 and will appreciate your help on the correct way to achieve this. I have tried to use the code below but battle to get it right. registerForm :: Monad m => Form Text m Register registerForm = Register <$> "name" .: text Nothing <*> "options" .: choice options Nothing where options= [(Option1,"Option1"),(Option2,"Option2"), (Option3, "Option3"),Option4,"Option4"] registerView:: View H.Html -> H.Html registerView view = do label "name" view "Name: " inputText "name" view H.br label "options" view "Options: " inputSelect "options" view H.br I get the following error when I compile my code: /root/work/src/Adapter/HTTP/Web/Auth.hs:107:29: error: • Couldn't match type ‘Text’ with ‘Char’ arising from the literal ‘"Option1"’ • In the first argument of ‘pack’, namely ‘"Option1"’ In the expression: pack "Option1" In the expression: (Option1, pack "Option1") | 107 | options= [(Option1,pack "Option1"),(Option2,pack "Option2"),(Option3,pack "Option3"),(Option4,pack "Option4")] Your help will be highly appreciated.

1 0

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 17 Feb '20

17 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 17 Feb '20

17 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

Taking over maintainership of cautious-file (or does anyone know of an alternative?)
by Brent Yorgey 15 Feb '20

15 Feb '20

The cautious-file package http://hackage.haskell.org/package/cautious-file has not been updated by the maintainer, Robin Green, since 2013 (though there have been a few Hackage trustee updates since then). The linked source repository was hosted on patch-tag.com and no longer exists. I tried contacting the maintainer on January 25 but have not heard back. I hereby announce my intention to take over as maintainer of the package. (As a side note, as far as I know my diagrams-haddock package is the only thing on Hackage that depends on it.) Alternatively, if anyone knows of a different, actively maintained package that provides similar functionality, I'd love to hear about it! -Brent

3 4

ghc runtime linker problem on i386
by Olaf Klinke 15 Feb '20

15 Feb '20

Dear Cafe, I'm experiencing strange behaviour on an old i386 machine when interpreting Haskell code on the fly: The same code runs from GHCi and fails as compiled executable. It might be a GHC runtime linker problem but I'm not sure. I successfully built haskintex and IHaskell with stack 2.1.3 on that machine. Both programs are supposed to interpret Haskell code at runtime: IHaskell uses the GHC API while haskintex uses hint, which itself is a wrapper for the GHC API. Therefore I suspect the problem lies in the usage of the GHC API itself. Both programs fail at runtime with the same error: $LIBDIR/ghc-prim-0.5.3/HSghc-prim-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_` When adding -dynamic to the ghc-options field in the package cabal file, the error goes away. Minimal code to reproduce is below. The i386 machine has no system ghc, no cabal, no ghcup and I wiped the $HOME/.stack directory before running "stack build". On x86-64 the error does not occur regardless of the -dynamic flag. Should I file a bug report or is this expected behaviour? If this is a bug, who should I file the bug against? Olaf {-- put this as app/Main.hs in a new stack project --} module Main where import Language.Haskell.Interpreter -- hint main :: IO () main = putStrLn =<< hintstuff hintstuff :: IO String hintstuff = fmap (either show show).runInterpreter $ do setImports ["Prelude"] interpret "1+2" (as :: Int)

1 0

Interpreting synchronized streams (pre-IO monad Haskell)
by Jiri Jakes 13 Feb '20

13 Feb '20

Heλλo! Before introduction of IO monad, first versions of Haskell used synchronised streams [1]: main :: [Response] -> [Request] where Response and Request were ADTs containing all possible actions and responses: data Request = ReadFile Name | ... | AppendChan Name String | ... data Response = Success | Str String | Bn Bin | Failure ... I wanted to write an interpreter of this representation using a simplified version: import System.Environment (getArgs) data Response = Success | StrList [String] data Request = GetArgs | PutStr String eval :: Request -> IO Response eval GetArgs = StrList <$> getArgs eval (PutStr s) = putStrLn s >> return Success main' :: [Response] -> [Request] main' ~(StrList args : _) = [ GetArgs, PutStr (show args) ] main :: IO () main = ??? I can imagine how interpreting main' could work, thanks to laziness. However, when actually trying to implement it, I get lost. I cannot figure out how could I read requests (result of calling main') before having something to pass to main'. Having a look at ancient version of GHC [2] didn't help either. Is it actually possible without some low-level tricks? Perhaps using mutually recursive functions? Or by converting to continuations somehow? Thank you! Jiri [1] http://haskell.org/definition/haskell-report-1.0.ps.gz [2] https://downloads.haskell.org/~ghc/0.29/ghc-0.29-src.tar.gz

2 1

Re: [Haskell-cafe] [ANN] Documentation for base-4.13.0.0 & GHC 8.8.1
by 石井大海 13 Feb '20

13 Feb '20

Oops, sorry I've sent the question only to Fumi mistakingly. Here I re-send to Cafe. Sorry! > 2020/02/13 13:28、石井大海 <konn.jinro(a)gmail.com>のメール: > > Hi, > > What's the difference with documentations already distributed with GHC Users' Guide? > > * https://downloads.haskell.org/~ghc/8.8.2/docs/html/ <https://downloads.haskell.org/~ghc/8.8.2/docs/html/> > * https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/ghc-8.8.2/inde… <https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/ghc-8.8.2/inde…> > * https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/index.html <https://downloads.haskell.org/~ghc/8.8.2/docs/html/libraries/index.html> > > Are they hooglable? > >> 2020/02/13 13:20、Fumiaki Kinoshita <fumiexcel(a)gmail.com <mailto:fumiexcel@gmail.com>>のメール: >> >> It seems unlikely that they will be uploaded to Hackage anytime soon, so I decided to host them on my server. >> >> http://docs.hask.moe/base-4.13.0.0/index.html <http://docs.hask.moe/base-4.13.0.0/index.html> >> >> GHC 8.8.1: http://docs.hask.moe/ghc-8.8.1/index.html <http://docs.hask.moe/ghc-8.8.1/index.html> >> >> Hope this helps >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> >> Only members subscribed via the mailman list are allowed to post. >

2 1

Re: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
by tomas gallegos 13 Feb '20

13 Feb '20

Hello there, My name is Tomas Gallegos and I specialize in functional programming using Haskell. I am very interested in this Haskell job position. It would be great if we could talk to discuss this position further and maybe schedule an interview. Thank you for your time and consideration, I look forward to hearing from you.(Attached to this email is my resume). Regards, Tomas Gallegos

6 7

[ANN] Documentation for base-4.13.0.0 & GHC 8.8.1
by Fumiaki Kinoshita 13 Feb '20

13 Feb '20

It seems unlikely that they will be uploaded to Hackage anytime soon, so I decided to host them on my server. http://docs.hask.moe/base-4.13.0.0/index.html GHC 8.8.1: http://docs.hask.moe/ghc-8.8.1/index.html Hope this helps

1 0

[ANN] BNFC-meta 0.6.1 release -- embedded Happy parsers
by Artem Pelenitsyn 13 Feb '20

13 Feb '20

Hello! BNFC-meta 0.6.1 has been released. The library [1,2] allows you to define simple parsers inside your source files using BNF-like formalism by the way of Template Haskell. A couple of small example applications are hosted here [3]. Details are described in the Haskell '11 paper [4] (preprint [5]). Compared with the previous release, support for recent GHCs is added. Also a minor problem with spaces after closing parenthesis in pretty-printer is fixed courtesy GitHub user @mbuszka. [1]: http://hackage.haskell.org/package/BNFC-meta [2]: https://github.com/ulysses4ever/BNFC-meta [3]: https://github.com/ulysses4ever/BNFC-meta-examples [4]: https://dl.acm.org/doi/10.1145/2096148.2034689 [5]: http://www.cse.chalmers.se/~patrikj/papers/MetaDSL_preprint_20110325.pdf -- Cheers, Artem

1 0

Re: [Haskell-cafe] [Job] Cloudseal seeks Haskell Software Engineers
by tomas jose gallegos 13 Feb '20

13 Feb '20

Hello there, My name is Tomas Gallegos and I specialize in functional programming using Haskell. I am very interested in this Haskell job position. It would be great if we could talk to discuss this position further and maybe schedule an interview. Thank you for your time and consideration, I look forward to hearing from you.(Attached to this email is my resume). Regards, Tomas Gallegos Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

help designing a function
by PICCA Frederic-Emmanuel 12 Feb '20

12 Feb '20

Hello, I try to write a software, which takes a stack of images and produce a data cube. Depending on the user input obtain via an .ini file, these cube are computed from different kind of projection. For now I have only two projection QxQyQzProjection and HklProjection. I prepare the InputXXX for the processXXX functions from the BinocularConfiguration and a function (InputType -> a) mkInputQxQyQz :: FramesQxQyQzP a => BinocularsConfig -> (InputType -> a) -> IO (InputQxQyQz a) processQxQyQz :: FramesQxQyQzP a => InputQxQyQz a -> IO () mkInputHkl :: FramesHklP a => BinocularsConfig -> (InputType -> a) -> IO (InputHkl a b) processHkl :: FramesHklP a => InputHkl a b -> IO () now I want to write this kind of function, which use the right Projection depending on the type find in the BinocularsConfig processProjection :: Show a => BinocularsConfig -> (InputType -> a) -> IO () processProjection c' f = do print c' case (ptype . bProjection $ c') of QxQyQzProjection -> do i <- mkInputQxQyQz c' f print i processQxQyQz i HklProjection -> do i <- mkInputHkl c' f print i processHkl i return () Indeed when I compile this code, I have an Error explaining that a FramesHklP a constrain is missing from the processProjection function. and idem for the FramesQxQyQzP. so I can add both constrains, but in that case I need to implement the two interfaces for each type a. Indeed this is wrong the `a` is for a specific projection thus I can not create an instance for each kind of Projection. I do not know If I am clear, but I do not know how to organise my code in order to be able to write this processProjection method. any help would be appreciate. thanks Frederic

1 0

[Job] Hackworth are hiring a Haskell developer, full time, on-site in London
by Drew Hess 11 Feb '20

11 Feb '20

[Hi Haskellers! Apologies if you’ve already seen this on Reddit or Hacker News.] Hackworth are hiring a full-time Haskell developer in London. This is an on-site role, at our office in Shoreditch. Salary range: £70,000-£80,000 per year In this role, you'll help lead the research phase of our first product: a programming language optimized for learning to program, rooted in functional programming concepts, with a particular focus on the visualization of program execution. You'll be responsible for designing several prototype languages, exploring the programming language and computer education research literature for ideas, and explaining these designs and their trade-offs to your colleagues. Once the research phase concludes, you'll help lead the development phase of the product, the result of which will be a novel interactive programming environment for children. We're targeting the end of 2021 for initial beta testing with schools and external organizations. We expect to open-source the product at some point during the development phase. You'll have the option of leading that open source effort, if you wish. This role does not include any on-call, devops, or customer support requirements. You'll be focused exclusively on writing Haskell and creating an innovative programming environment for kids. For more information, please see the full job posting on our website: https://www.hackworthltd.uk/jobs/20200204/. ## Tech Our software stack is entirely Haskell and Nix. We use macOS on the desktop, and NixOS and AWS everywhere else. If you prefer Linux on your desktop, we can probably arrange that. ## About us Hackworth Ltd is a well-financed, bootstrapped, private limited company based in London. Our purpose is to make programming relevant to the interests of children of all backgrounds. We're committed to building a sustainable, ethical, socially responsible business. We serve children and schools; therefore, we’ll never fund our business by selling ad placements or exploiting compulsion loops via loot boxes or micro-transactions. See here for more: https://www.hackworthltd.uk/about/ ## Applying To apply for this role, you should meet the following requirements: * The equivalent of (approximately) 2 years' experience writing Haskell, in either an industrial or research setting. It need not have been all at one organization, nor one contiguous block of time. * You can be on-site at our London office at least 4 days per week. * You're eligible to work in the United Kingdom. If you're familiar with any of the following topics, that's a definite plus, and you should mention it in your application; but please note that these are not required for the role: * Dependent types * Gradual typing * Refinement types * Total functional programming * Program synthesis * Structured editing a la Hazel or similar * Block-based programming (e.g., Scratch) * Virtual machines designed for functional languages, e.g., Landin's SECD. ## To apply To apply for this role, please submit a resume/CV to careers(a)hackworthltd.com. Even if you’re unsure about your fit, or if you have any additional questions about the role, or about working at Hackworth in general, please get in touch! Hackworth are committed to diversity. We are an equal opportunities employer and do not discriminate on the grounds of gender, sexual orientation, marital or civil partner status, pregnancy or maternity, gender reassignment, race, colour, nationality, ethnic or national origin, religion or belief, disability or age.

1 0

OpenBSD stack executable
by mike thomas 09 Feb '20

09 Feb '20

Hi there. I want to use stack on OpenBSD 6.6. In the absence of an official executable, I've been looking for instructions on how to bootstrap stack *without* a preexisting stack executable, with no luck. I've got GHC 8.6.4, Cabal 2.4.0 and Happy 1.19.5. Any thoughts? Cheers Mike Thomas

2 1

MonadThrow and Either instance
by PICCA Frederic-Emmanuel 08 Feb '20

08 Feb '20

Hello, I try to parse a config file and extract a (Path Abs Dir) from these files So I have a parser as defined in config-ini So I need a function with this signature pathAbsDir :: Text -> Either String (Path Abs Dir) pathAbsDir t = do d <- try $ parseAbsDir (unpack . uncomment $ t) case d of Right v -> Right v Left e -> Left (show e) since I am using parseAbsDir wi this signature parseAbsDir :: MonadThrow m => FilePath -> m (Path Abs Dir) I would like to know how to write the patAbsDir method for now I have this error message src/Hkl/Binoculars/Config.hs:82:8-49: error: • Couldn't match type ‘[Char]’ with ‘GHC.Exception.SomeException’ arising from a use of ‘try’ • In a stmt of a 'do' block: d <- try $ parseAbsDir (unpack . uncomment $ t) In the expression: do d <- try $ parseAbsDir (unpack . uncomment $ t) case d of Right v -> Right v Left e -> Left (show e) In an equation for ‘pathAbsDir’: pathAbsDir t = do d <- try $ parseAbsDir (unpack . uncomment $ t) case d of Right v -> Right v Left e -> Left (show e) | 82 | d <- try $ parseAbsDir (unpack . uncomment $ t) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I understand that the MonadThrow instance of Either is for Either Exception a But I want (Either String a). Cheers Frederic

7 8

Seeking help to generalize this ..
by Debasish Ghosh 07 Feb '20

07 Feb '20

Hi - How can I generalize the following pattern to an arbitrary list of functions ? compose :: (Monad m) => (Foo -> m Foo) -> (Foo -> m Foo) -> (Foo -> m Foo) -> Foo -> m Foo compose f1 f2 f3 acc = do a <- f1 acc b <- f2 a f3 b Any help please .. regards. -- Debasish Ghosh http://manning.com/ghosh2 http://manning.com/ghosh Twttr: @debasishg Blog: http://debasishg.blogspot.com Code: http://github.com/debasishg

6 7

sharing
by Tom Schouten 06 Feb '20

06 Feb '20

Hi, Is there currently a consensus on what is the best way to embed a pure dataflow language while keeping control over value sharing? I have a stream processing language that has a monadic interface (a -> b -> m c) to track variable sharing so it can compile down to C or Verilog, but I would like to create an expression interface layer on top (s a -> s b -> s c) that still allows me to recover the underlying monad representation to implement sharing. I got used to writing in monadic form but I really can't sell this to EEs... Other than a TH or syntax frontend, unsafe tricks, or Conal's compiling to categories which requires a plugin (I believe), is there another way? Cheers, Tom

5 12

Re: [Haskell-cafe] sharing
by Tom Schouten 06 Feb '20

06 Feb '20

(Reply from Sebastiaan Joosten) I've tried something similar before but ran into a lot of cases where verbose intermediate type annotations where necessary to resolve double-wrapping ambiguities because the monad is abstract in my case: xor :: DSL m r => r S -> r S -> m (r S)) Where r is representation wrapper, m is the associated compiler/interpreter, and S is a phantom tag. On 2/5/20 10:05 AM, Sebastiaan Joosten wrote: > Hi Tom, > > It wasn't entirely clear to me what you're looking for, so I'm > probably way off here > >> On 5 Feb 2020, at 08:59, Tom Schouten <tom(a)zwizwa.be >> <mailto:tom@zwizwa.be>> wrote: >> >> asking people to give up expressions while they work just fine in C >> or Verilog > > If all you care about is writing hardware expressions, how about > providing a handful of self-lifting operators? Below is an example of > what I mean (you'd replace the list applicative with your own > applicative). I'm freely combining pureed and unpureed Booleans in the > 'test' example, which would presumably be what your EE's write (I've > only given them a single self-lifting operator, so they're still stuck > writing pretty boring code). Does this help? > > Best, > Sebastiaan > > PS: I'm not replying to haskell-cafe only because my mails bounce > there due to a technical issue that's entirely on my side, feel free > to add this back onto the haskell-cafe thread > > {-# LANGUAGE FlexibleInstances, FlexibleContexts, > MultiParamTypeClasses #-} > class Pureable a b where > maybePure :: a -> b > instance Pureable a [a] where > maybePure = pure > instance Pureable [a] [a] where > maybePure = id > (.&&) :: (Pureable a [Bool], Pureable b [Bool]) > => a -> b -> [Bool] > a .&& b = (&&) <$> maybePure a <*> maybePure b > test :: [Bool] -> [Bool] > test x = (True .&& x) .&& (False .&& x)

2 2

Re: [Haskell-cafe] ListT version leveraging Traversable
by Olaf Klinke 04 Feb '20

04 Feb '20

Dear Juan, Traversables indeed are intimately connected with monad transformers: Two monads are known to commute if one monad (say t) yields a functor on the Kleisli category of the other monad (say m). If you write down what this means for fmap, you get the following type signature: (a -> m b) -> t a -> m (t b) which is the type of mapM and traverse. So does every Traversable monad t yield a monad transformer? Not quite. A functor has to obey the law fmap f.fmap g = fmap (f.g) and this is not given simply by the existence of traverse, you need: traverse f <=< traverse g = traverse (f <=< g). As Li-yao Xia pointed out, it is fairly easy to find a counterexample to <*> = ap for TravListT. But you could of course define <*> = ap and the problem is gone. However, a lawful monad satisfies join . join = join . fmap join and there is a counterexample for TravListT: type M a = TravListT [] a -- [] is not commutative x :: M Int x = TravListT ([[1,2],[3,4]]) -- ((join.join) xxx) /= ((join.fmap join) xxx) xxx :: M (M (M Int)) xxx = let xx = [[x, x],[x]] in TravListT [[TravListT xx,TravListT (reverse xx)]] I have not attempted to make this counterexample minimal, so please forgive the long term. Your claim (3) that [] is the monad of non-determinism is at least not entirely true. Lists modulo ordering and multiplicity are a model of non-determinism. In other words, if Data.Set was a monad then this was your model of non-determinism. Indeed, we have ((sort.runTravListT.join.join) xxx) == ((sort.runTravListT.join.fmap join) xxx) so the counterexample is only a counterexample because the ordering matters for equality. If you're modelling non-determinism, you may safely use the deprecated ListT knowing that the monad laws are violated only due to ordering and multiplicity. Olaf

2 1

ANN:: provenience-0.1.0.0
by Olaf Klinke 04 Feb '20

04 Feb '20

Dear Haskellers, I just uploaded the first release of provenience to hackage [1]. The provenience package contains a monad transformer that lets you automatically track intermediate values and data dependencies in a computation. The philosophy behind it is that computation is done on one machine, while review of the algorithm is done by a third party. We make only minimal assumptions about the third party. Typically, we target static html as documentation format. The resulting data flow graph can be exported as various document formats via Pandoc. If desired, a machine-readable representation of each node is recorded as well. At my company we use provenience to generate invoices paired with Excel files out of the same Haskell application. The provenience Package will be presented at BOB conference [2] in Berlin end of this month. Regards, Olaf [1] https://hackage.haskell.org/package/provenience-0.1.0.0 [2] https://bobkonf.de/2020/klinke.html

1 0

CfP: Haskell Symposium 2020
by Tom Schrijvers 04 Feb '20

04 Feb '20

================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2020 New Jersey, United States 27--28 August, 2020 http://www.haskell.org/haskell-symposium/2020/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2020 will be co-located with the 2020 International Conference on Functional Programming (ICFP). Like last year, we will be using a lightweight double-blind reviewing process. See further information below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. Submission Details ================== Early and Regular Track ----------------------- The Haskell Symposium uses a two-track submission process so that some papers can gain early feedback. Strong papers submitted to the early track are accepted outright, and the others will be given their reviews and invited to resubmit to the regular track. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2020 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors’ own related work should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Early track: Submission deadline: 20 March 2020 (Fri) Notification: 24 April 2020 (Fri) Regular track and demos: Submission deadline: 15 May 2020 (Fri) Notification: 26 June 2020 (Fri) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell20.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Travel Support ============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://pac.sigplan.org) Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permssion-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html) Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available) Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Arthur Azevedo de Amorim Carnegie Mellon University Manuel Chakravarty Tweag I/O / IOHK Jan Christiansen Flensburg University of Applied Sciences Youyou Cong Tokyo Institute of Technology Pierre-Evariste Dagand CNRS Anton Ekblad Chalmers University of Technology Jurriaan Hage Universiteit Utrecht Graham Hutton University of Nottingham José Pedro Magalhães Standard Chartered Clare Martin Oxford Brookes University Andrey Mokhov Jane Street Shin-Cheng Mu Academia Sinica Nikolaos Papaspyrou National Technical University of Athens Simon Peyton Jones Microsoft Research Cambridge Norman Ramsey Tufts University Exequiel Rivas INRIA Tom Schrijvers (chair) KU Leuven Martin Sulzmann Karlsruhe University of Applied Sciences If you have questions, please contact the chair at: tom.schrijvers(a)kuleuven.be<mailto:tom.schrijvers@kuleuven.be> ================================================================================

1 0

ListT version leveraging Traversable
by Juan Casanova 03 Feb '20

03 Feb '20

Hello haskell-cafe, I am going to be stating a series of things about the way I understand some things right now (both theoretical ideas and the general consensus on the Haskell community about some topics). Please feel free to point out to any of these assumptions if you think it is flawed. 1. ListT is deprecated as a Monad Transformer because for some monads it is not a proper transformer. 2. (1) translates literally into the fact that the MonadTrans instace for ListT is unlawful for some monads. 3. The fundamental concept of List as a monad is non-determinism, it is the notion of doing operations on non-deterministic results and generating new non-deterministic results. 4. A "correct" ListT transformer would therefore: 4.1. Be lawful. 4.2. Represent the notion of non-deterministic results tied within the monad they are transforming. 4.3. Be such that when applied to the Identity monad it returns the original List monad. 5. There is no canonical and accepted by the community alternative to ListT which fulfills both points in (4). 6. But there is no proof that (5) is a theoretically necessary thing. I am putting this this way because what I am going to claim now is that I have found one such transformer, that satisfies both points in (4). Therefore, it is very likely that some of my assumptions are flawed. Note that I make no claim that my transformer is unique up to isomorphism. It just seems that what I did does the job, but maybe there are other *fundamentally distinct* ways to fulfill the two points in (4)? Is that maybe the reason why there is no canonical version of ListT? But then why haven't I seen any of those versions, including the one I will present? (By the way, I already see different versions, but which correspond to the same idea just traversing lists in different orders. Permutations of it, so to speak). So, onto what I've done. I am going to be using an example to explain why I think what I did fulfills (4.2). This is not a proof, but I feel that (4.2) is not a formal statement anyway (is there a formal way to express this?). The basic problem I see with implementing ListT correctly is that the non-determinism produces non-deterministic monadic results, and because we wish to keep the non-determinism only to the results and not to the transformed monad itself, there is a need to choose what monadic results we keep. But then, I think, we have a "canonical" way of doing a collection of monadic results: Traversals. And what a wonderful thing that lists are the most natural version of Traversable. Therefore, what I did is to use traverse (and concat, which relies on Foldable which is a superclass of Traversable) to collect the monadic results and produce something that fulfills the type signature that ListT should have. Here's the code. The only really interesting bit is bind: data TravListT m a = TravListT {runTravListT :: m [a]} instance Functor m => Functor (TravListT m) where fmap f (TravListT m) = TravListT (fmap (fmap f) m) instance Applicative m => Applicative (TravListT m) where pure x = TravListT (pure (pure x)) (TravListT fs) <*> (TravListT xs) = TravListT (getCompose ((Compose fs) <*> Compose xs)) instance Monad m => Monad (TravListT m) where return = pure (TravListT ma) >>= f = TravListT (ma >>= (\l -> (concat <$> (traverse (runTravListT . f) l)))) instance MonadTrans TravListT where lift m = TravListT (return <$> m) I also (believe) I have proof that TravListT is a lawful MonadTrans, but I have skipped that here since this is already long enough. If you want to talk about that, we can. This allows me to do the things I would expect of a ListT, such as having a stateful list [1,3,7,11], applying a stateful operation wrapped around a Maybe monad that non-deterministically multiplies and sums each result with the current state with a special case, and increases the state by 1, and produce the stateful, non-deterministic result of doing all of that: let mposns = return [1,3,7,11] :: StateT a Maybe [Int] let tmposns = TravListT mposns let f = \n -> TravListT (StateT (\s -> if (s == n) then Nothing else (Just ([s * n,s + n],s+1)))) let rr = tmposns >>= f runStateT (runTravListT rr) 100 Just ([100,101,303,104,714,109,1133,114],104) runStateT (runTravListT rr) 1 Nothing So I guess my overall question is: why is this not a more standard thing? Are any of my assumptions wrong? Is there something wrong with this monad transformer? Is this really a new idea (I'd be surprised)? Thanks and sorry for the long email, Juan Casanova. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 1

Looking-up a TyCon of a type exposed from public module but defined in hidden module
by 石井大海 03 Feb '20

03 Feb '20

Hi cafe, I'm currently writing GHC Type-Checker Plugin [ghc-typelits-presburger], which enhances type-inference involving type-level naturals using Presburger arithmetic. To process constraints properly, I need an access to TyCons of `TrueSym0`, `FalseSym0`, `GTSym0`, etc. from `singletons` package. These types are exposed by public modules, e.g. Data.Singletons.Prelude, but it seems that they are originally defined in private module `Data.Singletons.Prelude.Instances`. I first tried, to retrieve the `TyCon` for `TrueSym0`, the following: ``` insts <- lookupModule (mkModuleName "Data.Singletons.Prelude.Instances") (fsLit "singletons") singTrueSym0 <- tcLookupTyCon =<< lookupOrig insts (mkTcOcc "TrueSym0") ``` But this results in the following compile-time error: ``` ghc: panic! (the 'impossible' happened) (GHC version 8.6.5 for x86_64-apple-darwin): Unable to resolve module looked up by plugin: Data.Singletons.Prelude.Instances Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ``` Then, I tried to lookup `TrueSym0` from exposed module, say Data.Singletons.Prelude: ``` prel <- lookupModule (mkModuleName "Data.Singletons.Prelude") (fsLit "singletons") singTrueSym0 <- tcLookupTyCon =<< lookupOrig prel (mkTcOcc "TrueSym0") ``` But this resulted in the following error: ``` • Can't find interface-file declaration for type constructor or class singletons-2.5.1:Data.Singletons.Prelude.TrueSym0 Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the type signature: ... ``` Is there any way, in GHC API, to lookup symbols exported from public module but originally defined in hidden module? Thanks, [ghc-typelits-presburger]: https://github.com/konn/ghc-typelits-presburger -- Hiromi ISHII konn.jinro(a)gmail.com

2 1

Error trying to build haskell-dbus on FreeBSD
by Brandon Martin 02 Feb '20

02 Feb '20

I am trying to build haskell-dbus on FreeBSD 12.1. I have tried with stack 2.1.3.1, and with cabal 2.4.0.0. I am seeing this error: Not in scope: type constructor or class ‘HsType’ Full error: https://gist.github.com/codedmart/2b04438566ed8e985d909db7d426649c HsType is part of ghc unless I am missing something. I am new to using FreeBSD as I usually use Linux. This package builds fine for me on Linux. Thanks -- Brandon Martin

9 16

Haskell positions available at Luminous Computing.
by David Banas 02 Feb '20

02 Feb '20

Hi all, I have 3 Haskell openings on my team at Luminous Computing, Inc. https://www.luminouscomputing.com/ <https://www.luminouscomputing.com/> We are using Haskell to build our tools (chip design, architecture explorer, and customer design compiler). And I’m looking for a different individual to own each tool. Of course, in a start-up flexibility is key, but that’s the official notion of how things would be arranged. Please, take a brief look at our web site. And, if you think you might be interested, let me know, so we can chat and explore a potential fit. Thanks, David Banas Chief Architect Luminous Computing, Inc.

6 5

Haskell Language Server admin
by Alan & Kim Zimmerman 01 Feb '20

01 Feb '20

For those of you who are not yet aware of it, the teams involved in haskell-ide-engine and ghcide got together last weekend in Bristol[1], and decided to join efforts, and to coordinate this in a new project, which we provisionally called 'ide', assuming it would always be in a haskell context. It turns out this was not such a wise decision, and after a very quick, very unscientific poll on github, publicized on twitter only, we have decided to instead call the project something meaningful, and will be renaming it to 'haskell-language-server' instead, which makes it clear what the project actually is. The informal poll can be seen at [2] Alan [1] https://neilmitchell.blogspot.com/2020/01/one-haskell-ide-to-rule-them-all.… [2] https://github.com/haskell/ide/issues/29#issuecomment-580747082

1 0

Ann: vector 0.12.1.1 release!
by Carter Schonwald 01 Feb '20

01 Feb '20

https://hackage.haskell.org/package/vector-0.12.1.1 it has A LOT of bug fixes, a few little improvements, enjoy!

3 6

Call for Papers: PACMPL issue ICFP 2020
by Sam Tobin-Hochstadt 31 Jan '20

31 Jan '20

PACMPL Volume 4, Issue ICFP 2020 Call for Papers accepted papers to be invited for presentation at The 25th ACM SIGPLAN International Conference on Functional Programming Jersey City, USA http://icfp20.sigplan.org/ ### Important dates Submissions due: 3 March 2020 (Tuesday) Anywhere on Earth https://icfp20.hotcrp.com Author response: 21 April (Tuesday) - 24 Apri (Friday) 14:00 UTC Notification: 8 May (Friday) Final copy due: 1 July (Wednesday) Conference: 18 August (Sunday) - 23 August (Friday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL <https://pacmpl.acm.org/>) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicized Calls for Papers, like this one. ### Scope [PACMPL](https://pacmpl.acm.org/) issue ICFP 2020 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; macros; pattern matching; type systems; type inference; dependent types; session types; gradual typing; refinement types; interoperability; domain-specific languages; imperative programming; object-oriented programming; logic programming; probabilistic programming; reactive programming; generic programming; bidirectional programming. * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; runtime systems; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling; build systems; program synthesis. * Foundations: formal semantics; lambda calculus; program equivalence; rewriting; type theory; logic; category theory; monads; continuations; control; state; effects; names and binding; program verification. * Analysis and Transformation: control flow; data flow; abstract interpretation; partial evaluation; program calculation. * Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; graphics and multimedia; GPU programming; scripting; system administration; security. * Education: teaching introductory programming; parallel programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2020 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such when submitted and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is **Tuesday, March 3, 2020**, Anywhere on Earth (<https://en.wikipedia.org/wiki/Anywhere_on_Earth>). This deadline will be strictly enforced. **Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from <https://www.acm.org/publications/authors/submissions>. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from <http://sigplan.org/Resources/Author/#acmart-format>. There is a limit of **25 pages for a full paper or Functional Pearl** and **12 pages for an Experience Report**; in either case, the bibliography will not be counted against these limits. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. Supplementary material can and should be **separately** submitted (see below). See also PACMPL's Information and Guidelines for Authors at <https://pacmpl.acm.org/authors.cfm>. **Submission**: Submissions will be accepted at <https://icfp20.hotcrp.com/> Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. **Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on **Tuesday, April 21, 2020**, to read reviews and respond to them. **Supplementary Material**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should **not** be submitted as part of the main document; instead, it should be uploaded as a **separate** PDF document or tarball. Supplementary material should be uploaded **at submission time**, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). **Authorship Policies**: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at <https://www.acm.org/publications/authors/information-for-authors>. **Republication Policies**: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at <http://www.sigplan.org/Resources/Policies/Republication>. ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2020. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns. **PACMPL issue ICFP 2020 will employ a two-stage review process.** The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on **May 8, 2020**. Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After four weeks (June 5, 2020), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within four weeks and hence that conditionally accepted papers will in general be accepted in the second phase. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection. **PACMPL issue ICFP 2020 will employ a lightweight double-blind reviewing process.** To facilitate this, submitted papers must adhere to two rules: 1. **author names and institutions must be omitted**, and 2. **references to authors' own related work should be in the third person** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limit for the final versions of papers will be increased by two pages to help authors respond to reviewer comments and mandatory revisions: **27 pages plus bibliography for a regular paper or Functional Pearl, 14 pages plus bibliography for an Experience Report**. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options: open access on payment of a fee (**recommended**, and SIGPLAN can cover the cost as described next); copyright transfer to ACM; or retaining copyright but granting ACM exclusive publication rights. Further information about ACM author rights is available from <http://authors.acm.org>. * PACMPL is a Gold Open Access journal. It will be archived in ACM’s Digital Library, but no membership or fee is required for access. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. * ACM offers authors a range of copyright options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article [Why CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open Access Scholarly Publishers Association. * We intend that the papers will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit <http://www.acm.org/publications/acm-author-izer-service> to learn how to create links for free downloads from the ACM DL. * The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to *two weeks prior* to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. * At least one author of each accepted submission will be expected to attend and present that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents. In extraordinary circumstances, at the discretion of the principal editor, alternative presentation methods may be approved for specific papers. The canonical example is where all authors are denied visas to the ICFP host country, in which case a nonauthor may be deputized to present, or various electronic substitutes may be considered. We list these options in the interest of transparency, but please keep in mind that, most years, no exceptions are granted. This option is not meant, e.g., to excuse cases where authors find themselves double-booked with other meetings (so, at the time of submitting a paper, please do keep the days of the conference reserved on at least one author’s calendar). ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page, and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. #### Experience Reports The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works -- or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the papers and in any citations, the title of each accepted Experience Report must end with the words "(Experience Report)" in parentheses. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better to submit it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Artifact Evaluation Co-Chairs: Ben Lippmeier (UNSW, Australia) Brent Yorgey (Hendrix College, USA) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Leonidas Lampropoulos (University of Maryland, USA) Jennifer Hackett (University of Nottingham, UK) Conference Manager: Annabel Satin (P.C.K.) ### PACMPL Volume 4, Issue ICFP 2020 Principal Editor: Adam Chlipala (MIT, USA) Review Committee: Andreas Abel (Gothenburg University, Sweden) Nada Amin (Harvard University, USA) Edwin Brady (University of St. Andrews, UK) William E. Byrd (University of Alabama at Birmingham, USA) David Darais (University of Vermont) Richard A. Eisenberg (Bryn Mawr College, USA) Matthew Fluet (Rochester Institute of Technology, USA) Makoto Hamana (Gunma University, Japan) Fritz Henglein (Department of Computer Science, University of Copenhagen (DIKU) and Deon Digital, Denmark) Jan Hoffmann (Carnegie Mellon University, USA) Robbert Krebbers (Delft University of Technology, Netherlands) Neel Krishnaswami (Computer Laboratory, University of Cambridge, UK) Geoffrey Mainland (Drexel University, USA) Magnus O. Myreen (Chalmers University of Technology, Sweden) Atsushi Ohori (Tohoku University, Japan) Frank Piessens (KU Leuven, Belgium) Nadia Polikarpova (University of California San Diego, USA) Jonathan Protzenko (Microsoft Research, USA) Jerome Simeon (Clause, France) KC Sivaramakrishnan (IIT Madras, India) External Review Committee: Danel Ahman (University of Ljubljana, Slovenia) Aws Albarghouthi (University of Wisconsin-Madison, USA) Kenichi Asai (Ochanomizu University, Japan) Patrick Bahr (IT University of Copenhagen, Denmark) Stephanie Balzer (Carnegie Mellon University, USA) Jean-Philippe Bernardy (University of Gothenburg, Sweden) Sandrine Blazy (Univ Rennes-IRISA, France) Benjamin Canou (OCamlPro, France) Giuseppe Castagna (CNRS - Université de Paris, France) Jesper Cockx (TU Delft, Netherlands) Youyou Cong (Tokyo Institute of Technology, Japan) Leonardo De Moura (Microsoft Research, USA) Sebastian Erdweg (JGU Mainz, Germany) Ronald Garcia (University of British Columbia, Canada) Jennifer Hackett (University of Nottingham, UK) Troels Henriksen (University of Copenhagen, Denmark) Gabriele Keller (Utrecht University, Netherlands) Delia Kesner (IRIF, France / University of Paris Diderot, France) Shriram Krishnamurthi (Brown University, United States) Jan Midtgaard (University of Southern Denmark, Denmark) Andrey Mokhov (Jane Street, USA) J. Garrett Morris (University of Kansas, USA) Stefan Muller (Carnegie Mellon University, USA) Rasmus Ejlers Møgelberg (IT University of Copenhagen, Denmark) Cyrus Omar (University of Chicago, USA) Dominic Orchard (University of Kent, UK) Ivan Perez (NIA / NASA Formal Methods) Brigitte Pientka (McGill University, Canada) Juan Pedro Bolívar Puente (Independent Consultant, Sinusoidal Engineering) Norman Ramsey (Tufts University, USA) Christine Rizkallah (UNSW Sydney, Australia) Tiark Rompf (Purdue University, USA) Guido Salvaneschi (Technische Universität Darmstadt, Germany) Tom Schrijvers (KU Leuven, Belgium) Chung-chieh Shan (Indiana University, USA) Vincent St-Amour (Northwestern University, USA) Aaron Stump (The University of Iowa, USA) Nicolas Tabareau (Inria, France) Ross Tate (Cornell University, USA) Dimitrios Vytiniotis (DeepMind, UK) John Wiegley (DFINITY, USA) Beta Ziliani (FAMAF, UNC and CONICET, Argentina)

1 0

Do new versions of GHC work on older versions of macOS?
by Troels Henriksen 30 Jan '20

30 Jan '20

When new versions of GHC come out, I suppose they work on the newest macOS. But what is the oldest macOS they will support? Is there a policy in place? If not, do they tend to work in practice? I am particularly concerned with the binary distributions. -- \ Troels /\ Henriksen

2 1

Domain modeling
by Jean Lopes 30 Jan '20

30 Jan '20

Hi! I'm trying to encode a domain which is full of simple records, and a lot of field name clashes. Here is a simple example, a.k.a. 1:1 with the domain-spec: data C001 { > -- other stuff > indMov :: Bool > } > data C170 { > -- other stuff > indMov :: Bool > } There is ~148 records with this field (indMov), all with the same meaning. What are my options to encode this in Haskell? - Prefix all record fields to avoid name clashes? - Use *DuplicateRecordFields*? - Typeclasses??? - other options I am not aware of? which would you prefer? and why of course :) Thanks, Jean Lopes

5 5

Compilers written in Haskell?
by David Banas 29 Jan '20

29 Jan '20

Can anyone provide a list of compilers written in Haskell? Sent from my iPhone

9 9

Need help using a typeclass within an existing API
by Debasish Ghosh 28 Jan '20

28 Jan '20

Hi - (Apologies for the long post) I need some help integrating a typeclass based functionality within an existing API. I am using Control.Monad.Validate for my validation of objects. Here's a simple function based on this .. debit :: forall m. (MonadReader Env m, MonadValidate [Error] m) => Y.Dense "USD" -> Account -> m Account debit amount = updateBalance ((-1) * amount) Now I want to make a change in the API where I would like to fetch the account from some database based on account number. For this I have a typeclass as below .. class (Monad m) => AccountDB m where query :: Text -> m (Maybe Account) .. elided details and I am using persistent - so I have an instance of this class as follows .. -- | Instance of AccountDB for `SqlPersistT` (which is `ReaderT SqlBackend`) instance (MonadIO m) => AccountDB (SqlPersistT m) where query ano = get (AccountKey ano) .. other details elided My question is how can I integrate this typeclass within the above API ? I tried as yet another constraint in the function .. debit :: forall m. (MonadReader Env m, MonadValidate [Error] m, AccountDB m) => Y.Dense "USD" -> Text -> m Account debit amount accNo = do maybeAccount <- query accNo maybe (refuteErr $ InvalidAccountNumber accNo) (updateBalance ((-1) * amount)) maybeAccount This compiles but I don't get the proper instance of the typeclass when I run it - possibly due to the reason that the "m" cannot be the same for AccountDB as the other constraints. And I don't want to hardcode SqlPersistT in the function debit as I would like to be able to run it with other instances of the typeclass as well (example for testing I may like to test against a HashMap). What would be an idiomatic approach to this kind of composition ? 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 1

Issues requesting permission to publish packages
by Victor Adossi 28 Jan '20

28 Jan '20

Hi Haskell-Cafe, I recently tried to upload a package to hackage and sent an email to hackage-trustees(a)haskell.org to request to be added to the uploaders group. Unfortunately my email was undelivered due to an SPF Failure -- here's what the error emailed to me looks like: > <one-of-the-maintainers(a)personal-email.com> (expanded from > <hackage-trustees(a)haskell.org>): host > host.personal-email.com[xxx.xxx.xxx.xxx] said: 550 5.7.23 > <one-of-the-maintainers(a)personal-email.com>: Recipient address > rejected: Message rejected due to: > SPF fail - not authorized. Please see > http://www.openspf.net/Why?s=mfrom;id=vados@vadosware.io;ip=<IP of > haskell.org server>;r=<UNKNOWN> > (in reply to RCPT TO command) It looks like the SPF settings on my domain forbid the bounce off of hackage-trustees to the individual trustee that was picked. Two points: - This seems like an unintended leaking of information (I have one of the emails of the trustees, via the error message) - How else can I request the ability to become a package uploader? Thanks, Victor

2 2

Munich Haskell Meeting, 2020-01-27 @ 19:30
by Leah Neukirchen 26 Jan '20

26 Jan '20

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, January 27 at Augustiner-Gaststätte Rumpler 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-jan-2020/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Problem using Persistent
by Debasish Ghosh 26 Jan '20

26 Jan '20

Hi - I have an entity declaration in persistent as follows: share [mkPersist sqlSettings { mpsGenerateLenses = True, mpsPrefixFields = False }, mkMigrate "migrateAll"] [persistLowerCase| Account accountNo Text accountType AccountType accountHolderName Text accountOpenDate UTCTime default=CURRENT_TIME accountCloseDate UTCTime Maybe default=NULL currentBalance MoneyUSD rateOfInterest Double Primary accountNo deriving Show |] I am getting this compilation error .. • No instance for (Generic (Key Account)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (aeson-1.4.6.0:Data.Aeson.Types.ToJSON.ToJSON (Key Account)) | 40 | share [mkPersist sqlSettings { mpsGenerateLenses = True, mpsPrefixFields = False }, mkMigrate "migrateAll"] [persistLowerCase| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... and another exactly similar for FromJSON What exactly is going wrong here ? I am not using json in the above definition. regards. -- Debasish Ghosh http://manning.com/ghosh2 http://manning.com/ghosh Twttr: @debasishg Blog: http://debasishg.blogspot.com Code: http://github.com/debasishg

2 1

[ANN] bz2 library
by Vanessa McHale 25 Jan '20

25 Jan '20

Hi all, I wrote another high-level wrapper around libbz2, https://matrix.hackage.haskell.org/#/package/bz2. It includes low-level bindings (via c2hs) and a bundled copy of bzlib 1.0.8 as well. Cheers, Vanessa McHale

1 0

[ANN] nix-freeze-tree-0.1.0.0 - Freeze a tree using fixed-output derivations
by Jack Kelly 25 Jan '20

25 Jan '20

I have just pushed an initial release of nix-freeze-tree[1] to Hackage. `nix-freeze-tree` is a utility that walks a directory tree, and writes out Nix expressions which rebuild that tree. The generated expressions have two important properties: 1. Each file in the tree is built by a separate fixed-output derivation, and 2. Directories are built by derivations that symlink their contents recursively. If you are using `nix copy` to ship a derivation between nix stores, copying the derivation built by evaluating the output of `nix-freeze-tree` can reuse existing files in the destination store, as fixed-output derivations can be checked against a hash before copying. I use this to speed up deploys to my personal website. Running `nix-freeze-tree` on the output from my site generator and importing the result means that `nix copy` only uploads new files, instead of copying a single giant derivation containing every image on the site. The code is on Sourcehut[2]; bug reports[3] and patches[4] are welcome. The repository also has a Nix helper function for running the tool on your own derivations. Best, -- Jack [1]: https://hackage.haskell.org/package/nix-freeze-tree-0.1.0.0 [2]: https://git.sr.ht/~jack/nix-freeze-tree/ [3]: https://todo.sr.ht/~jack/nix-freeze-tree [4]: https://lists.sr.ht/~jack/nix-freeze-tree-discuss

1 0

[ghc-steering-committee] The GHC Committee welcomes its new members
by Joachim Breitner 24 Jan '20

24 Jan '20

Dear Haskell community, the GHC Steering committee welcomes three new members, Alejandro Serrano Mena, Cale Gibbard and Tom Harding. We are happy to see that there is continued interest in our work, and are looking forward to having fresh insights and energy on the committee. They take the seat of Sandy Maguire, who we thank for this productive work during his tenure. As you might notice, we picked more candidates than we filled slots. This is not because Sandy’s productivity need three people to fill. The idea is that there is no reason to turn away a motivated contributor just to stick to the arbitrary 10 members. Instead, we will aim at “roughly 10”, and probably not call for new members until we have dropped below that number again. On behalf of the committee, Joachim Breitner PS: Alejandro, Cale and Tom, please send me your github handles and subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

1 0

Taking over double-conversion on Hackage
by Rinat Stryungis 21 Jan '20

21 Jan '20

Hi everyone, The double-conversion package seems unmaintained. I'd like to take over as maintainer. I have actually forked the repository, added new functionality, tests, and updated the original Google library: https://github.com/haskell-mouse/double-conversion I was advised to consider taking over the maintenance of double-conversion. I tried to contact Bryan O'Sullivan (the maintainer) a few times during the 2 years (!) using all available communication methods (e-mail, LinkedIn). He answered only once and asked me to send an e-mail. I did it but without any effect. I would still prefer not to have this responsibility, but I would also like people to be able to use the new functionality without creating redundant forks.

1 0

a sort of chunk
by PICCA Frederic-Emmanuel 21 Jan '20

21 Jan '20

Hello, I need to write some code in order to do some computations with stack of images coming from hdf5 files. Each computation done per images is quite intensive, so I want to do this on multiple cores of my computer (24 in my case) A stack of images is composed of a list of files. each file contain n images. So I decided to proceed like this: create a data type which represent a chunk of this stack. data Chunk = Chunk { filename :: FilePath , from :: Int , to :: Int } And indeed the full stack is [Chunk] Now since I have n core, I need to split the full stack in equivalent chunk of images. Just for example. at the begining I have this image stack 30476 images [Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00077.nxs" 0 698,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00078.nxs" 0 1104,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00079.nxs" 0 1510,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00080.nxs" 0 1914,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00081.nxs" 0 2318,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00082.nxs" 0 2720,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00083.nxs" 0 2169,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00084.nxs" 0 2445,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00085.nxs" 0 2720,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00086.nxs" 0 490,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00087.nxs" 0 812,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00088.nxs" 0 1133,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00089.nxs" 0 1454,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00090.nxs" 0 1773,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00091.nxs" 0 2090,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00092.nxs" 0 2406,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00093.nxs" 0 2720] so i need to write a function which do something like chunksOf chunksOf :: Int -> [Chunk] -> [[Chunk]] In this case I need to create chunk of 1325 images, so the finla result should be [ [Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00077.nxs" 0 698,Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00078.nxs" 0 627] , [Chunk "/nfs/ruche-sixs/sixs-soleil/com-sixs/2019/Run3/FeSCO_Cu111/sample2_ascan_omega_00078.nxs" 627 1104, ...] ... ] I would like your help in order to give me advices or help me find information whcih can help me implement this chunksOf method. thanks for your help. Frederic

2 9