May 2017 - Haskell-Cafe

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 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 01 Jul '17

01 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

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

stack, git, directory structure
by Dennis Raddle 26 Jun '17

26 Jun '17

I have a few basic questions about my project organization using stack. I'm going to have several executables and a hierarchical library. For instance, let's say I'm going to call my overall system "cac" (computer aided composition). I'll have imports like import Cac.Util import Cac.Search import Cac.Search.Algo1 -- some modules that assist things import XDoc import XDoc.Parse and so on. I'll have executables named 'foo', 'bar', etc. So would the following be correct? - call the directory where I put all stack packages $PROJ - call the top level of my specific project $PROJ/cac, which will have $PROJ/cac/cac.cabal - I'll have the following files and dirs: - modules: - $PROJ/cac/src/Cac.hs - $PROJ/cac/src/Cac/ - $PROJ/cac/src/Cac/Util.hs - $PROJ/cac/src/Cac/Search.hs - $PROJ/cac/src/Cac/Search/ - $PROJ/cac/src/XDoc.hs - $PROJ/cac/src/XDoc/ - $PROJ/cac/src/XDoc/Parse.hs - executables: - $PROJ/app/foo.hs - $PROJ/app/bar.hs Also, if I'm going to use git, would my .git/ directory be at $PROJ/cac/.git/ ? thanks D

3 4

listing include files in a cabal file
by Patrick Pelletier 03 Jun '17

03 Jun '17

I have some C code in my Cabal package, consisting of both *.c and *.h files. Obviously, the *.c files get listed in "c-sources". But I'm trying to figure out where to list the *.h files. Right now, I'm not listing them anywhere, and my package compiles just fine. According to the Cabal users guide, there is an "includes" field and an "install-includes" field. The "includes" field seems to only be relevant when compiling via C. And even when compiling via C, wouldn't the include already be picked up when it is part of the foreign declaration, e. g.: foreign import ccall unsafe "tmr_tag_data.h TMR_bytesToHex" c_TMR_bytesToHex :: Ptr Word8 -> Word32 -> CString -> IO () As for the "install-includes" field, I don't think my header files would need to be installed, because they're internal to my package. The package's interface is entirely in Haskell. Should I just put my include files in "extra-source-files", so they get added to the package, but otherwise aren't treated specially? Or should I be using "includes" and/or "install-includes"? Thanks, --Patrick

2 2

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 02 Jun '17

02 Jun '17

> On Tue May 30 19:43:30 UTC 2017, Richard Eisenberg wrote: > > On May 24, 2017, at 3:13 AM, Anthony Clayden wrote: > ... Some functions are defined by an ordered set of equations. > Some (that is, class methods) are defined by > an unordered set of equations, perhaps distributed across modules. > Both models are useful. Sure. Let a 100 schools of thought contend. >>> ... [equality constraints and equality guards are] >>> different, but I think the equality guard is useless >> I agree adds nothing over repeating the typevar. And I've already agreed the potential for confusion with (~) constraints. So noted. I'll include it in the proposal, where a wider audience can bikeshed. >> I see two main uses/benefits: >> 1. avoids the need for non-linear patterns in the head > > Agreed that it would do this. But why is that important? > I was in part thinking of your wondering-out-loud earlier in the Partially applied thread https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127078.html If we want to part-apply a type Fun which has a non-linear lhs, how does that go with your case-equation style? Adapting that earlier example: > type family F a b where > F a a = () -- added an equation > F Int b = b > F a Bool = a would really mean > type F a b = case a of > _ -> case b of -- ?? _ match-all > a -> () -- ?? re-using typevar a > Int -> b > _ -> case b of > Bool -> a > _ -> F a b > > 2. visually points up the 'non-apartness' vs an, um. > > "apartness guard" > > > > (When I was figuring out Andy A-M's 2013 example, > > I rewrote the non-linear patterns with ~ guards, > > so I could figure out the apartness guards > > esp for the semi-apart instances. > > I posted the later workings to your blog > > Somehow, this is more convincing. But I'm still not > convinced on this point. Happily, you don't need to > convince me -- put in the proposal what you like and then > we can debate a concrete design. > > >> [except as a type-level "let", I suppose].) > > They would work as "let", I think: > > > instance Either a a | a ~ SomethingBigAndUgly where ... > > Note that the `a` is not introduced in the guard. Ah, OK. I get you. Equally that could be > instance Either a b | a ~ b, a ~ SomethingBigAndUgly where .. > > > Ok thanks, yes [TypeError] helps. > > Nevertheless it seems disergonomic > > to write an instance for a type-equal case, > > even with a helpful error message; > > when what you want is: no such instance. > > You could always view > > > instance TypeError ... => C Int Bool > > as sugar for > > > instance C Int Bool fails Yes I understand that. But no I don't want any instance. (Sugar on rotten fruit doesn't hide the smell.) There are (or at least used to be) all sorts of side-effects from there in effect being an instance that matched. > > What I can see will be awkward is backwards > > compatibility: can a class/type family with guards > > coexist with CTFs and with classes using overlap? > > Sure. There would be no problem with this. The new idea is > just that: new. I don't see it as getting rid of anything > we already have. Perhaps some day we could think about > removing OverlappingInstances, but we certainly don't have > to do that at the same time as introducing instance > guards. (I do like that name, too.) > OK. Perhaps you're seeing something I can't. To adapt your example from a parallel message, suppose: > module A > > class {-# INSTANCEGUARDS #-} C a where ... > instance C (Maybe a) | a /~ Int where ... > instance C (Maybe Int) where ... > > module B > -- knows nothing of InstanceGuards > import A > > instance {-# OVERLAPPABLE #-} C (Maybe Bool) where ... I want to reject that `(Maybe Bool)` instance. Even though it would legitimately be OVERLAPPABLE by (Maybe a) (that is, without the `a /~ Int` guard). Furthermore I might want a class to be InstanceGuarded, even though the instances I declare don't themselves need guards. (That is, I'm wanting to avoid 'future' overlaps in modules that import the class.) > > > > I'll have a crack at the proposal. > > Great. Thanks! (Likely I'll need some help with the protocols.) AntC

2 1

Vim syntax file typo
by Matthew Fernandez 02 Jun '17

02 Jun '17

Hello Haskell Cafe, The attached patch fixes what looks to be a typo in a comment in the Haskell Vim syntax file. Pretty trivial, but I'm mailing it to this list as it's listed as the maintainer of the file and I believe that's the Vim policy. Please let me know if there's somewhere more appropriate I should send this or if you'd prefer me to just submit it as a pull request on the Vim Github. Thanks, Matt

1 1