- Haskell-Cafe - Haskell.org

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 10 Aug '18

10 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 08 Aug '18

08 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 08 Aug '18

08 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 06 Aug '18

06 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

Re: [Haskell-cafe] Working around floating-point inaccuracies
by Olaf Klinke 06 Aug '18

06 Aug '18

Michail, Each plane in 3d space is determined by a single linear equation with 3 unknowns. Essentially the equation is what pointOnPlane evaluates. Two planes are equal if the system of linear equations consisting of both equations has rank 1. This is a standard concept of linear algebra, hence the answer to your problem (and code for a good implementation) should be found in the literature on that subject - numerical linear algebra. Google "numerical rank of a matrix". The concepts you are looking for is the "condition number" or "operator norm". You could try to enforce an invariant that the representation is always as nice as possible, numerically. If you are okay with a vector space over the rational numbers, you could represent your planes by an equation with integer coefficients, which makes equality testing independent of floating point issues. Olaf

1 0

Fixity of ($) and (.) vs. (&) and (>>>)
by Frederik Hanghøj Iversen 05 Aug '18

05 Aug '18

With function composition I can easily write something like h . g . f $ expr However if I want to write the equivalent in left-to-right composition style: expr & f >>> g >>> h This is not possible due to a parsing error arising from the fixity of the operators. (>>>) is provided by Control.Arrow and (&) by Data.Function. My question is, would it not be better to *decrement* the fixity of (&) by one or *increment* the fixity of (>>>) by one (probably rather the latter)? -- Regards *Frederik Hanghøj Iversen*

2 1

ANN: lsp-test-0.1.0.0
by Luke Lau 05 Aug '18

05 Aug '18

My GSoC 2018 project (and first package!), lsp-test <https://hackage.haskell.org/package/lsp-test-0.1.0.0>, is now available on Hackage. It allows you to carry out functional end-to-end tests at a high level for LSP <https://microsoft.github.io/language-server-protocol/> servers, and we’re currently using it in haskell-ide-engine <https://github.com/haskell/haskell-ide-engine>. Many thanks to Alan Zimmerman and Zubin Duggal for their invaluable help this summer. Hopefully it will help improve your LSP servers, or maybe entice you to make one for your language!

1 0

Re: [Haskell-cafe] [random-fu] sampleRVar with StdGen in RWS?
by dominic＠steinitz.org 05 Aug '18

05 Aug '18

> > I suppose you could write an orphan instance for RWST if you really > > wanted to. > > That's what I'll most probably do for my small project, but I was > wondering whether it made sense to make a pull request to random-fu. To > me, having a MonadRandom for both StateT and RWST seems very natural. Please do make a PR - I will accept it immediately :) Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com Twitter: @idontgetoutmuch

2 1