- Haskell-Cafe - Haskell.org

Learning & Haskell Job Board
by Alex Mesropians 13 Aug '18

13 Aug '18

Hey All, Just wanted to share Workshub <http://t.sidekickopen13.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs5…> with you all for those looking to hire Haskell engineers or want to see for yourself whats out there! We also have a learn section which is forever growing with new FP related content! We are always also looking for people to contribute to! thanks, Alex

1 0

Google Summer of Code : CodeWorld
by Krystal Maughan 13 Aug '18

13 Aug '18

Hi All, I wrote a blog post on features I worked on this summer for Google Summer of Code in CodeWorld. Hope you enjoy it! Thank you for giving me the opportunity to work in Haskell this summer! https://medium.com/@krystal.maughan/breaking-the-space-time-barrier-with-ha… Best, Krystal

1 0

cpphs broken on GHC 8.6.1
by Vanessa McHale 12 Aug '18

12 Aug '18

As of the latest release of GHC 8.6.1, cpphs no longer compiles. Anyone happen to know what's going on? Thanks! -- *Vanessa McHale* Functional Compiler Engineer | Chicago, IL Website: www.iohk.io <http://iohk.io> Twitter: @vamchale PGP Key ID: 4209B7B5 Input Output <http://iohk.io> Twitter <https://twitter.com/InputOutputHK> Github <https://github.com/input-output-hk> LinkedIn <https://www.linkedin.com/company/input-output-global> This e-mail and any file transmitted with it are confidential and intended solely for the use of the recipient(s) to whom it is addressed. Dissemination, distribution, and/or copying of the transmission by anyone other than the intended recipient(s) is prohibited. If you have received this transmission in error please notify IOHK immediately and delete it from your system. E-mail transmissions cannot be guaranteed to be secure or error free. We do not accept liability for any loss, damage, or error arising from this transmission

2 1

hs-boot and (micro)lenses
by Francesco Ariis 12 Aug '18

12 Aug '18

Hello cafe, I have some problem setting up an appropriate .hs-boot module. I attach a .tar.gz'd cabal folder, so you can immediately test it with `cabal new-repl`. I had a file like this -- datatypes data A = A { _i :: Int, _b :: B } type AS a = State A a data B = B (AS ()) makeLenses ''A -- functions f :: B f = B $ i .= 18 So I decided to split it up in 2 files to test hs-boot in the wild: -- A.hs ------- data A = A { _i :: Int, _b :: B } type AS a = State A a makeLenses ''A -- B.hs ------- data B = B (AS ()) f :: B f = B $ i .= 18 Well, I don't know how to write A.hs-boot. I tried this: module A where import Lens.Micro.Platform data A b :: Lens' A B but ghc rightfully complains that he doesn't know about B, and if I slap an `import B` in the .hs-boot then I have another import-cycle. What's the way out of that? The project I am dealing with is bigger than this problem and I would really love to keep functions and related datatypes nearby for mental sanity. As I wrote above, attached you can find a .tar.gz with everything set up to replicate this -F

2 2

Fwd: [Haskell] [ANNOUNCE] GHC 8.6.1-beta1 available
by Dan Burton 11 Aug '18

11 Aug '18

I've generated a stack.yaml which should allow most stack users to install this ghc release via stack. https://gist.github.com/DanBurton/43b5f5155fdd1affd02f6e86f37da9ae e.g. $ mkdir test-new-ghc && cd test-new-ghc $ wget https://gist.github.com/DanBurton/43b5f5155fdd1affd02f6e86f37da9 ae/raw/6cb25068fcfae7d70739b7927248a80518192ad6/stack.yaml $ stack setup $ stack repl Once installed in this way, you can simply use: compiler: ghc-8.6.0.20180810 compiler-check: match-exact In any project's stack.yaml in order to build with this version of ghc. -- Dan Burton ---------- Forwarded message ---------- From: Ben Gamari <ben(a)well-typed.com> Date: Fri, Aug 10, 2018 at 7:31 PM Subject: [Haskell] [ANNOUNCE] GHC 8.6.1-beta1 available To: GHC developers <ghc-devs(a)haskell.org>, GHC users < glasgow-haskell-users(a)haskell.org>, Haskell Cafe < haskell-cafe(a)googlegroups.com>, haskell(a)haskell.org Hello everyone, The GHC development team is very pleased to announce the first beta leading up to GHC 8.6.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-beta1 This beta fixes most of the bugs reported in the first two alphas and brings all of the core libraries up to their final release versions. The 8.6 release fixes over 300 bugs from the 8.4 series and introduces a number of exciting features. These most notably include: * Significantly better handling of macOS linker command size limits, avoiding linker errors while linking large projects * A new deriving mechanism, `deriving via`, providing a convenient way for users to extend Haskell's typeclass deriving mechanism * Quantified constraints, allowing forall quantification in contexts * An early version of the GHCi `:doc` command * The `ghc-heap-view` package, allowing introspection into the structure of GHC's heap * Valid hole fit hints, helping the user to find terms to fill typed holes in their programs * The BlockArguments extension, allowing the `$` operator to be omitted in some unambiguous contexts * The next phase of the MonadFail proposal, enabling -XMonadFailDesugaring by default A full list of the changes in this release can be found in the release notes: https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/ users_guide/8.6.1-notes.html This will very likely be the last release before the final 8.6.1 so do give it a thorough testing and, as always, report any issues you encounter. Thanks for your help! Cheers, - Ben _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

2 1

Aeson memory use
by Lana Black 09 Aug '18

09 Aug '18

Hello Cafe, Recently while trying to optimize some code, I noticed that aeson requires quite a substantial amount of memory when parsing map-like structures. The quick example I crafted [1] is quite surprising. In order to parse an 11 megabyte file aeson requires around 300 megabytes of memory (according to the heap profiler), and the total memory footprint (according to htop) jumps to around 700 megabytes. Is there a way to reduce this number to something less insane? I suspect that I might be doing something wrong here, but I can't exactly see what. [1] https://github.com/greydot/aeson-example

5 9

Call for Participation: ICFP 2018
by Lindsey Kuper 07 Aug '18

07 Aug '18

*** Early registration ends 27 August. *** ===================================================================== Call for Participation ICFP 2018 23rd ACM SIGPLAN International Conference on Functional Programming and affiliated events September 23 - September 29, 2018 St. Louis, Missouri, USA http://icfp18.sigplan.org/ ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. This year, ICFP is co-located with Strange Loop! Considering attending ICFP for the first time? See our brief explainer: https://icfp18.sigplan.org/attending/introduction-to-icfp * Overview and affiliated events: http://icfp18.sigplan.org/home * Program: http://icfp18.sigplan.org/program/program-icfp-2018 * Accepted papers: http://icfp18.sigplan.org/track/icfp-2018-papers * Registration is available via: https://regmaster4.com/2018conf/ICFP18/register.php Early registration ends 27 August, 2018. * Programming contest results: https://icfpcontest2018.github.io/ * Student Research Competition: https://icfp18.sigplan.org/track/icfp-2018-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference In addition to Strange Loop (9/26-9/28), there are several events co-located with ICFP: * Erlang Workshop (9/29) * Functional Art, Music, Modeling and Design (9/29) * Functional High-Performance Computing (9/29) * Haskell Implementors' Workshop (9/23) * Haskell Symposium (9/27-9/28) * Higher-order Programming with Effects (9/23) * ICFP Tutorials (9/27-9/29) * ML Family Workshop (9/28) * Numerical Programming in Functional Languages (9/27) * OCaml Workshop (9/27) * Programming Languages Mentoring Workshop (9/23) * Scala Symposium (9/28) * Scheme Workshop (9/28) * Type-Driven Development (9/27) Conference Organizers: General Chair: Robby Findler (Northwestern University, USA) Program Chair: Matthew Flatt (University of Utah, USA) Accessibility Chair: Alan Jeffrey (Mozilla Research, USA) Artefact Evaluation Co-Chair: Simon Marlow (Facebook, UK) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) PLMW Co-Chair: Dan Licata (Wesleyan University, USA) PLMW Co-Chair: David Van Horn (University of Maryland, USA) PLMW Co-Chair: Niki Vazou (University of Maryland, USA) Programming Contest Organizer: Matthew Fluet (Rochester Institute of Technology, USA) Publications Co-Chair: Alex Potanin (Victoria University of Wellington, New Zealand) Publicity Chair: Lindsey Kuper (UC Santa Cruz, USA) Student Research Competition Chair: Ravi Chugh (University of Chicago, USA) Student Volunteer Co-Captain: Jakub Zalewski (University of Edinburgh, UK) Student Volunteer Co-Captain: Spencer P. Florence (Northwestern University, USA) Treasurer and Conference Manager: Annabel Satin (P.C.K., UK) Video Co-Chair Jamie Willis (University of Bristol, UK) Video Co-Chair: Jose Calderon (Galois, USA) Workshops Co-Chair: Christophe Scholliers (Ghent University, Belgium) Workshops Co-Chair: David Christiansen (Galois, USA) Sponsors and industrial partners: Platinum supporters: Ahrefs Jane Street Standard Chartered X Gold supporters: DFINITY Facebook Mozilla McCormick School of Engineering, Northwestern University Silver supporters: Bloomberg Cal Poly Computer Science & Software Engineering Digital Asset Galois Microsoft Research Oracle Labs Tweag I/O Bronze supporters: Google IntelliFactory Kadena Obsidian Systems Systor Vest Well-Typed

1 0

Working around floating-point inaccuracies
by Michail Pevnev 07 Aug '18

07 Aug '18

Hello everyone! For a library I write at the moment, I made a class for approximate geometric equality comparisons (and dubbed it `ApproxEq`). It's not a very lawful class, but there is one invariant that should hold absolutely always - if two entities coincide but have different representations, they should compare "equal". All instances for my geometric entities seem to uphold this invariant (btw, QuickCheck is awesome). Except for the `Plane` type, which gives me a false negative once in about 50000 runs. I've chosen to represent planes by two vectors: an arbitrary point on a plane, and a normal. To test this invariant I translate the plane by a vector parallel to the plane, and then compare the translated plane with the original. The general pattern to these failures is that one of the coordinates of the origin point of the untranslated plane is huge compared to the other two - by 4-6 orders of magnitude, while the translation vector is not particularly big and has about the same magnitude as the two smaller coordinates. I suspect that this difference throws off the function that tests if a point belongs to a plane (which is in turn used in the equality comparison) by filling lower digits of participating numbers with floating-point garbage. I can live with this false negative, but I'd prefer not to. There probably is a clever way to work around it, I just can't find it. Any ideas? Thanks in advance. The relevant code is below. ``` -- | A plane is represented by an arbitrary point on it and a normal vector. data Plane a = Plane (V3 a) (V3 a) deriving (Show) instance (Epsilon a, Floating a) => ApproxEq (Plane a) where p1@(Plane o1 n1) ~== p2@(Plane o2 n2) = res where n1' = normalize n1 n2' = normalize n2 parallel = n1' ~== n2' antiparallel = (-n1') ~== n2' originsAreTheSame = o1 ~== o2 originsBelong = pointOnPlane p1 o2 || pointOnPlane p2 o1 res = (parallel || antiparallel) && (originsAreTheSame || originsBelong) -- | Return True if a point lies on a plane. pointOnPlane :: (Epsilon a, Floating a) => Plane a -> V3 a -> Bool pointOnPlane (Plane o n) v = nearZero $ delta `dot` n' where delta = normalize $ o - v n' = normalize n ``` -- Michail.

3 3

How to increase solver iterations?
by David Banas 07 Aug '18

07 Aug '18

Hi all, I’m getting this ghc compilation error: solveSimpleWanteds: too many iterations (limit = 4) Set limit with -fsolver-iterations=n; n=0 for no limit These are the only plug-ins I’m using: {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} {-# OPTIONS_GHC -fplugin TypeNatSolver #-} I’ve tried the following, one at a time: {-# OPTIONS_GHC -fplugin-opt=TypeNatSolver:solver-iterations=10 #-} {-# OPTIONS_GHC -fplugin-opt=TypeNatSolver:fsolver-iterations=10 #-} {-# OPTIONS_GHC -fplugin-opt=GHC.TypeLits.KnownNat.Solver:solver-iterations=10 #-} {-# OPTIONS_GHC -fplugin-opt=GHC.TypeLits.KnownNat.Solver:fsolver-iterations=10 #-} But, I always get, “(limit = 4)”. Does anyone know how to change the number of solver iterations? Thanks, -db

2 4

Bizarre GHC error.
by David Banas 05 Aug '18

05 Aug '18

Has anyone seen this kind of error from GHC? dca9047d694f:concat-learn a594349$ stack build :lenna concat-learn-0.2.0.0: build (lib + exe) Preprocessing library concat-learn-0.2.0.0... [6 of 6] Compiling ConCat.Learn.CNN.Conv ( src/ConCat/Learn/CNN/Conv.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/ConCat/Learn/CNN/Conv.o ) user error (Unexpected result from the SMT solver: Expected: success Result: (error "line 1515 column 22: unknown constant tn_1" ) ) -- While building custom Setup.hs for package concat-learn-0.2.0.0 using: /Users/a594349/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.24.2.0 build lib:concat-learn exe:lenna --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 I started seeing it when I started trying to use the someNatVal function.

2 1