February 2018 - Haskell-Cafe

Fwd: Safe TCP accept loop
by Sumit Raja 30 May '18

30 May '18

Hi, I sent this to beginners but got no responses so I'm hoping someone here can help. I’ve looked at https://wiki.haskell.org/Concurrency_demos/Graceful_exit and used(2) Using throwTo without the use of block and unblock. It runs on 8.2.1 with my limited testing. I can’t find out much about what the > 7.x GHC replacement for block/unblock is other than mask. What does the unblock do in acceptConnections'? Does this method of handling an accept loop still need masking of async exceptions ? If so where does this need to be done? I've got a version with async running for my specific application (https://bitbucket.org/sumitraja/hvrr/src/6927216597a35a9a0d7f2e55cca83fa5b7…) but I don't know if I need to unmask at any point so was hoping for some guidance. Thanks Sumit

2 4

Archival of community.haskell.org
by Mario Rogic 19 May '18

19 May '18

Hi all As announced back in 2015 <http://blog.haskell.org/post/7/the_future_of_community.haskell.org/> we have started archiving community.haskell.org services. We've created https://archives.haskell.org/, and the old projects mailing lists have been the first to be archived. Next on the list is the remainder of projects.haskell.org, and the code.haskell.org site. As always, you can email admin(a)h.o or hop on the #haskell-infrastructure freenode channel to provide feedback / concerns. Thanks - Mario

1 2

Join a transformer
by Michael Snoyman 11 Apr '18

11 Apr '18

I'm wondering if this pattern exists and has a name. We have the concept of joining a Monad: join :: Monad m => m (m a) -> ma How about joining a monad transformer? joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a I believe implementing this in terms of MonadTransControl[1] might be possible, but I was wondering if there's an already existing idiom for this. Michael [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130301-40/monad-control/Control-M…

5 5

PatternSignatures (rant)
by Johannes Waldmann 06 Apr '18

06 Apr '18

Dear all, (this is a rant - please ignore) why has "PatternSignatures" been renamed to "ScopedTypeVariables" (in ghc-6.10)? show me the alleged "type variable" in this code: do x :: Int <- [ 1 .. 10 ] ; return $ x^2 and why on earth do I need to use a language extension at all to get to the most basic thing of declarative programming: to declare the type of an identifier? This seriously hurts (me, at least) when teaching Haskell. Thanks - J.W.

4 4

Haskell to Ethereum VM ?
by Takenobu Tani 30 Mar '18

30 Mar '18

Hi cafe, Does anyone know about the code generator from Haskell's syntax to Ethereum VM language (bytecode)? That is, what corresponds to Solidity in Haskell. Although Solidity is interesting, it's difficult for me to achieve quality and safety. Does such a project already exist? Regards, Takenobu

6 12

[ANN] brittany-0.9.0.0 (on both hackage&stackage)
by lennart spitzner 25 Mar '18

25 Mar '18

- Implement `IndentPolicyLeft`: A layouting setting that disables "hanging indentation". This indentation mode may become default in the future. Only configurable via config-file for the time being. - (!) commandline interface is reworked slightly to support multiple inputs/outputs (`brittany --write-mode=inplace *.hs`). This removes the --input/--output flags. - Ensure compatibility with stackage - Change default global config path (old configs are still respected) - Improve support for per-project config - Fix several bugs and Improve language extension support full changelog at https://hackage.haskell.org/package/brittany-0.9.0.0/changelog brittany was recently added to stackage, and should hopefully be included in the next LTS release. -- lennart

1 1

A small milestone
by Simon Peyton Jones 11 Mar '18

11 Mar '18

Cherished friends Today is my sixtieth birthday. It is just over forty years since Phil and I called in at Yale on my way to FPCA, and floated the idea of Haskell with Paul Hudak<https://www.microsoft.com/en-us/research/publication/a-history-of-haskell-b…>. (It wasn't called Haskell then, of course.) Rather a lot of water has flowed under the bridge since then. GHC's bug tracker is up to 14,683 tickets; I have read every one of them. But the best thing is Haskell's rich community of smart, motivated, passionate, and friendly colleagues. There was a time when I knew every Haskell programmer on the planet, but we are far, far beyond that point. Now it's beyond me even to keep up with the huge wave of elegant and creative ideas, tools, libraries, and blog posts that you generate. (Kudos to Taylor - and doubtless other colleagues -- for the Haskell Weekly News<https://haskellweekly.news/>, which I love.) But despite its size, it's a community that is still characterised by a love of elegance, and a desire to distil the essence of an idea and encapsulate it in an abstraction, all tempered with respect and tolerance. We don't always live up to these ideals, but by and large we do. Thank you all. Onward and upward! Simon PS: as birthday recreation I'm working on https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts

6 6

Software engineer job situated in a PL research group
by Ryan Newton 28 Feb '18

28 Feb '18

Hi all, This posting is for a potentially long term position with the department. In the short term the work will be largely about sandboxing, containerization, and other low level systems stuff, but *all* the high-level software in the group is written in Haskell: https://iujobs.peopleadmin.com/postings/44056 The OOPSLA17 paper, "Monadic Composition for Deterministic, Parallel Batch Processing <https://2017.splashcon.org/event/splash-2017-oopsla-detflow-a-monad-for-det…>", should give an idea of what this initial project is about. The engineer would be co-located with a large Programming Languages group (6 faculty and a couple dozen Ph.D. students). University benefits are good and our college town combines culture and beautiful surroundings with convenience and affordability. Best regards, -Ryan

1 0

[ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 28 Feb '18

28 Feb '18

The GHC development team is pleased to announce the first (and likely final) release candidate of GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-rc1 This release will likely be the last release before the final 8.4.1 release, which, if things go well, will be released one week from today. Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release candidate is still affected by #14705, although this will certainly be resolved before the final release is made. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

3 5

Optimization demonstration
by Dušan Kolář 28 Feb '18

28 Feb '18

Dear Café, I'm trying to do very small, but impressive example about optimizations possible during Haskell compilation. So far, I can demonstrate that the following two programs (if compiled) perform computation in the same time: 1) main = putStrLn $ show $ sum $ map (*(2::Int)) [(1::Int)..(100000000::Int)] 2) main = putStrLn $! show $! sumup 1 0 sumup :: Int -> Int -> Int sumup n total = if n<=(100000000::Int) then sumup (n+1) $! total+(2*n) else total Nevertheless, I expect a question on comparison with C: 3) #include <stdio.h> int main(void) { long sum, i; sum = 0; for (i=1; i <= 100000000L; ++i) { sum += 2*i; } printf("%ld\n",sum); return 0; } Unfortunately, in this case the C is much more faster (it prints the result immediately), at least on my machine. Is it due to a fact that C compiler does a brutal optimization leading to compile-time evaluation, while ghc is not able to do that? I'm using -O2 -dynamic --make ghc compiler flags. For gcc for C compilation just -O2, running Arch Linux. Is there any option, how to force compile time evaluation? The reason, why I think it works this way is the fact, that when running out of long type values in C a code is generated that computes the values regularly (providing misleading value as a result) taking its time. Best regards, Dušan

6 8