June 2019 - Haskell-Cafe

How long does it take to add an entry to https://www.haskell.org/community/?
by Benjamin L. Russell 23 Jun '19

23 Jun '19

Twenty-three days ago, I added an entry to the list of Haskell communities at https://www.haskell.org/community/ and submitted a pull request to have the page (https://github.com/haskell-infra/www.haskell.org/blob/master/community.mark…) updated; however, the page still has not been updated. In addition, it seems that there are 3 other pull requests for the same page by other users that have also not been applied, the earliest of which dates from March 16. How long does it take to add an entry to https://www.haskell.org/community/? (I'm assuming that submitting a pull request to "Update community.markdown" on Github is the correct procedure for those users without write access to the page.) -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Computer Science Document Translator/Editor "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

1 0

Munich Haskell Meeting, 2019-06-25 @ 19:30
by Leah Neukirchen 23 Jun '19

23 Jun '19

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 25 at **Hirschgarten (self-service area)** at 19h30. The weather should be nice! 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-jun-2019/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1-alpha2 is now available
by Ben Gamari 22 Jun '19

22 Jun '19

George Colpitts <george.colpitts(a)gmail.com> writes: > Will 8.8.1 use llvm 7.0.1? I don't see it mentioned in the release notes. > Yes, this release will target LLVM 7. I'll add a mention to the release notes. Cheers, - Ben

1 0

HiW'19: Call for Talks
by Niki Vazou 21 Jun '19

21 Jun '19

Hey all, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP it is an ideal place to describe a Haskell library, a Haskell extension, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Deadline is June 28th. Call for Talks The 11th Haskell Implementors’ Workshop is to be held alongside ICFP 2019 this year in Berlin. 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 lightning 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 2019. 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, optimization 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 can be made via HotCRP at https://icfp-hiw19.hotcrp.com/ until June 28th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. 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. Invited Speakers - Lennart Augustsson & Satnam Singh Program Committee - Jose Calderon (Galois, Inc) - Jasper Van der Jeugt (Fugue) - Niki Vazou (IMDEA Software Institute) - Ningning Xie (The University of Hong King) - Brent Yorgey (Hendrix College) Best, Niki Vazou

1 1

ANN: network-3.1.0.1
by Evan Borden 20 Jun '19

20 Jun '19

Hello, I'm happy to announce the release of network-3.1.0.1. This release includes a few maintenance changes. http://hackage.haskell.org/package/network-3.1.0.1 Contributors ============ * Evan Borden @eborden * Jack Kelly @endgame * Kazu Yamamoto @kazu-yamamoto * Leif Metcalf @leifmetcalf Changes ======= You can view the changes on github. https://github.com/haskell/network/releases/tag/v3.1.0.1 Thank you to network's contributors for their continued support. -- Evan Borden

1 0

functional languages - pretty good for students!
by Dennis Raddle 19 Jun '19

19 Jun '19

I've been doing computer science tutoring for a few years in languages like Java and Python. I started teaching a 10th grade student Elm recently. I'd like to use Haskell at some point, but because he likes websites and games, Elm seemed more apropos. What I'm discovering is that a functional language like Elm is fairly natural to him and he's learning quickly! Our lessons prior to Elm (including Python, Java, and JavaScript at this point) are extracurricular and he hasn't put much study in-between lessons, so his progress has been slow. I don't think he's developed many "programming muscles." But now, his progress in Elm is faster. One factor, I think, is how concise functional code is. He hasn't developed much "programmer's eye" up to now (by which I mean scanning a lot of code quickly) but Elm, being much shorter, is easier for him to grasp at a glance. He also thinks the algebraic data model is cool. He sees how it's related to classes and subclasses, but he appreciates how relatively simple it is. Mike

2 1

How to define classy lenses for polymorphic types that involve singletons?
by Peter Simons 18 Jun '19

18 Jun '19

Hi, I am trying to combine the lens library's 'makeClassy' feature with a type that's polymorphic over a singleton type: > {-# LANGUAGE DataKinds, FlexibleInstances, FunctionalDependencies, GADTs, > KindSignatures, RankNTypes, TemplateHaskell, TypeFamilies > #-} > > import Control.Lens > import Data.Singletons > import Data.Singletons.TH > > data Sex = Male | Female > deriving (Show, Eq, Ord, Bounded, Enum) > > genSingletons [''Sex] > > data Person (sex :: Sex) = Person { _name :: String, _email :: String } > deriving (Show, Eq) > > makeClassy ''Person Lens generates a class definition that looks sensible to me: class HasPerson a (sex :: Sex) | a -> sex where person :: Lens' a (Person sex) email :: Lens' a String name :: Lens' a String {-# MINIMAL person #-} Furthermore, I also need a type SomePerson to hide the phantom type so that I can store people of different sexes in the same container, i.e. [SomePerson]: > data SomePerson where > SomePerson :: Sing sex -> Person sex -> SomePerson > > fromPerson :: SingI sex => Person sex -> SomePerson > fromPerson p = SomePerson Sing p > > toPerson :: SomePerson -> (forall sex. Sex -> Person sex -> a) -> a > toPerson (SomePerson s p) f = f (fromSing s) p Here is where I've run into trouble. In theory, I should be able to make SomePerson an instance of HasPerson, define person :: Lens' SomePerson (Person sex) to access the Person type inside of it, and that would allow me to use 'name' and 'email' for SomePerson just the same as for Person. However, it seems impossible to define that function because it leaks the universally quantified 'sex', so function does not type-check. I have a somewhat awkward work-around that translates lenses on Person to SomePerson > somePerson :: (forall sex. Lens' (Person sex) a) -> Lens' SomePerson a > somePerson l = lens (\(SomePerson _ p) -> view l p) > (\(SomePerson s p) x -> SomePerson s (set l x p)) and that allows me to define: > type SomePerson' (sex :: Sex) = SomePerson > > instance HasPerson (SomePerson' sex) sex where > person = undefined -- cannot type check because 'sex' would leak > name = somePerson name > email = somePerson email I'm not particularly happy with that solution, though. Is there maybe a way to make this work such that I can avoid defining 'name' and 'email' manually? Or is there a clever alternative way to define HasPerson such a 'person' method for SomePerson is possible? Best regards Peter

2 2

Lenses and Nested Maps
by Henry Laxen 18 Jun '19

18 Jun '19

Hi Cafe, Suppose I have: s :: Map String (Map Int Char) s = M.fromList [("alice", M.fromList [(5,'a')]), ("bob", M.fromList [(6,'b')])] Is there any way to modify the 'b' entry easily using lenses? Thanks in advance. Best wishes, Henry Laxen

4 3

[ANNOUNCE] GHC 8.8.1-alpha2 is now available
by Ben Gamari 17 Jun '19

17 Jun '19

Hello everyone, The GHC team is pleased to announce the second and likely last alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha2 A draft of the release notes is also available [1]. This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release brings a number of fixes since alpha 1: * A number of linker fixes (#16779, #16784) * The process, binary, Cabal, time, terminfo libraries have all been bumped to their final release versions * A regression rendering TemplateHaskell unusable in cross-compiled configurations has been fixed (#16331) * A regression causing compiler panics on compilation of some programs has been fixed (#16449) * -Wmissing-home-modules now handles hs-boot files correctly (#16551) * A regression causing some programs to fail at runtime has been fixed (#16066) Due to on-going work on our release and testing infrastructure this cycle is proceeding at a pace significantly slower than expected. However, we anticipate that this investment will allow us to release a more reliable, easier-to-install compiler on the planned six-month release cadence in the future. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-…

2 2

Deprecation cycle for classes
by Tom Ellis 16 Jun '19

16 Jun '19

I am unsure how to change the name of a class in a library whilst providing a safe deprecation cycle for the users of the library. Suppose I have version 1 of my library with a class -- Version 1 class Foo a where foo :: a and I want to migrate it to version 3 as follows, but with a deprecation cycle provided by version 2 that allows code to work with either version 1 and 2, or 2 and 3. -- Version 3 class Bar a where bar :: a Then I can try to write version 2 as -- Version 2 {-# ConstraintKinds #-} class Foo a where bar :: a bar = foo foo :: a foo = bar type Bar = Foo This satisfies the following conditions: Users of versions 1 and 2 can use * The constraint Foo * The method foo * The class Foo and method foo for implementing their own instances User of versions 2 and 3 can use * The constraint Bar * The method bar * The method bar for implementing their own instances but they cannot jointly use * The *class* Bar for implementing their own instances (since Bar is not a class, just a Constraint) Is there any way I can write a version 2 that allows users to implement instances that work with both version 2 and version 3? Thanks, Tom

3 5