June 2017 - Haskell-Cafe

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

20 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@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 07 Apr '18

07 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 Implementors' Workshop Call for Talks
by Richard Eisenberg 04 Jul '17

04 Jul '17

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://icfp17.sigplan.org/track/hiw-2017 Oxford, UK, 9 September, 2017 Co-located with ICFP 2017 http://www.icfpconference.org/icfp2017/ Important dates --------------- Proposal Deadline: Thursday, 6 July, 2017 Notification: Thursday, 20 July, 2017 Workshop: Saturday, 9 September, 2017 The 9th Haskell Implementors' Workshop is to be held alongside ICFP 2017 this year in Oxford. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2017. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw17.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Richard A. Eisenberg -- chair (Bryn Mawr College) * Adam Gundry (Well-Typed) * Bartosz Nitka (Facebook) * Wren Romano (X, formerly Google[x]) * Alejandro Serrano Mena (Utrecht University) * Jan Stolarek (University of Edinburgh) Contact ------- * Richard A. Eisenberg <rae(a)cs.brynmawr.edu>

1 1

Re: [Haskell-cafe] Fast JSON validation - reducing allocations
by Ben Gamari 02 Jul '17

02 Jul '17

David Turner <dave.c.turner(a)gmail.com> writes: > On 11 May 2017 at 19:40, Ben Gamari <ben(a)smart-cactus.org> wrote: > >> Ccing Luke Maurer under the assumption that he will appreciate seeing >> the fruits of his labor. >> >> >> David Turner <dct25-561bs(a)mythic-beasts.com> writes: >> >> > Dear Café, >> > >> (snip) >> > >> > There's a copy of the relevant code for option 4 at >> > https://github.com/DaveCTurner/json-validator. I've hacked around with >> it a >> > bit since producing the numbers above, so it's now apparently a bit >> slower >> > than Aeson but allocates less too (~65kB). >> > >> > Could anyone help, e.g. by pointing me at the bit in the Core that is >> > allocating within the main loop? >> > >> While turning this over in my head I realized that this is the sort of >> program which may be helped significantly by GHC 8.2's improved join >> point handling. Indeed the timings seem to support this hypothesis: >> >> GHC 8.0.2 >> >> benchmarking json-validator/Automaton/testEvent >> time 22.84 μs (22.76 μs .. 22.94 μs) >> 1.000 R² (1.000 R² .. 1.000 R²) >> mean 22.84 μs (22.76 μs .. 22.94 μs) >> std dev 297.4 ns (221.8 ns .. 378.8 ns) >> >> Alloc rate 4,015,256,078,038 bytes per MUT second >> >> GHC 8.2 >> >> benchmarking json-validator/Automaton/testEvent >> time 9.221 μs (9.141 μs .. 9.318 μs) >> 0.998 R² (0.996 R² .. 1.000 R²) >> mean 9.163 μs (9.084 μs .. 9.356 μs) >> std dev 399.8 ns (193.0 ns .. 745.4 ns) >> variance introduced by outliers: 54% (severely inflated) >> >> Alloc rate 123,141,635 bytes per MUT second >> >> >> Wow! I suspect your allocations have now vanished. >> > > > Ooo, that's more like it. > > Could you run again using the following to get Criterion's estimate of the > allocations-per-call? > > json-validator-exe --regress allocated:iters +RTS -T >benchmarking json-validator/Automaton/testEvent Here it is, GHC 8.0.2 benchmarking json-validator/Automaton/testEvent time 34.81 μs (33.48 μs .. 36.10 μs) 0.991 R² (0.988 R² .. 0.994 R²) mean 34.04 μs (33.28 μs .. 34.99 μs) std dev 2.828 μs (2.423 μs .. 3.247 μs) allocated: 1.000 R² (1.000 R² .. 1.000 R²) iters 65924.651 (65895.364 .. 65951.510) y -4175.284 (-46736.295 .. 39814.235) variance introduced by outliers: 78% (severely inflated) GHC 8.2 benchmarking json-validator/Automaton/testEvent time 9.021 μs (8.923 μs .. 9.162 μs) 0.998 R² (0.994 R² .. 1.000 R²) mean 8.970 μs (8.905 μs .. 9.232 μs) std dev 341.4 ns (94.90 ns .. 711.7 ns) allocated: 0.973 R² (0.956 R² .. 0.984 R²) iters 343.033 (332.692 .. 354.606) y -7326.339 (-57269.638 .. 47222.231) variance introduced by outliers: 47% (moderately inflated) Cheers, - Ben

3 3

Nice clean code example?
by Han Joosten 01 Jul '17

01 Jul '17

I'd like to showoff some nice Haskell code to a CTO with no experience with FP. I promised to send him a small piece of Haskell so he could get an idea. The code should be easy to read, without obscure looking operators (so sorry, no lens, arrows stuff like that), optionally even do something interesting. Who has the nicest example laying around? (and yes, I need it by yesterday ;-) ) Thanks!

6 6

Re: [Haskell-cafe] Nice clean code example?
by Chris Wong 01 Jul '17

01 Jul '17

How about Hackagebot? https://github.com/lfairy/hircine/blob/master/brigitte/Hackagebot.hs https://github.com/lfairy/hircine/blob/master/brigitte/Utils.hs It involves a lot of concurrency, networking, and data structure manipulation -- all areas Haskell excels in. It avoids using advanced features as well (except maybe pattern synonyms, but those aren't visible in the code that uses them) Here are some numbers: its sibling Cargobot boasts 3+ months continuous uptime, with memory usage never going beyond 12 MB. It has never crashed. I expect Hackagebot to have similar metrics. On Jul 1, 2017 06:34, "Han Joosten" <han.joosten.han(a)gmail.com> wrote: I'd like to showoff some nice Haskell code to a CTO with no experience with FP. I promised to send him a small piece of Haskell so he could get an idea. The code should be easy to read, without obscure looking operators (so sorry, no lens, arrows stuff like that), optionally even do something interesting. Who has the nicest example laying around? (and yes, I need it by yesterday ;-) ) Thanks! _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

1 0

Dynamically linking frameworks on macOS
by Ryan Trinkle 01 Jul '17

01 Jul '17

Hi everyone, I'm trying to ensure that beginner-level code that uses reflex-dom can be built by simply calling 'ghc myFile.hs', provided that all the necessary libraries are available in ghc-pkg. This works on linux, but on macOS, it's currently necessary for the user to add '-dynamic' to the command line. In particular, without -dynamic, the linker fails to find "_OBJC_CLASS_$_NSURL", which is a symbol in the Foundation system framework. Apple doesn't support (and strongly discourages) statically linked executables[1], so it's not terribly surprising that this doesn't work. Is there anything I can do to avoid the need for -dynamic here? Thanks, Ryan [1] https://developer.apple.com/library/content/qa/qa1118/_index.html

2 2

Domain specific error diagnosis in Haskell, a proposal
by Alejandro Serrano Mena 30 Jun '17

30 Jun '17

Dear Haskellers, Some days ago Jurriaan Hage posted a video of our work on adding custom type error diagnosis to GHC. Here is a GHC proposal for incorporating this support in the mainline compiler: https://github.com/ghc-proposals/ghc-proposals/pull/59 Suggestions, criticisms and ideas are welcome. Alejandro

1 0

Source code location in IO?
by Tom Ellis 30 Jun '17

30 Jun '17

Is it compatible with the semantics of Haskell to have a function sourceLocation :: IO String which when run returns the source file location at which it is used? For example, suppose Main.hs is module Main where main = do putStrLn =<< sourceLocation putStrLn "Hello" putStrLn =<< sourceLocation It would print the following when run Main.hs:4 Hello Main.hs:6 and module Main where main = do let s = sourceLocation putStrLn =<< s putStrLn "Hello" putStrLn =<< s It would print the following when run Main.hs:4 Hello Main.hs:4 If this is not compatible with the semantics of Haskell, why not? I agree that the two programs must have the same denotation, but is there anything that requires them to have the same output when run? Tom

6 7