August 2016 - Haskell-Cafe

Re: [Haskell-cafe] Data.Set optimisations [was: library for set of heterogeneous values?]
by Anthony Clayden 26 Aug '16

26 Aug '16

> > On Mon, Aug 15, 2016 at 1:15 AM, Anthony Clayden wrote: > > "indirect jumps are particularly expensive on a modern > > processor architecture, because they fox the branch > > prediction hardware, leading to a stall of 10 or more > > cycles depending on the length of the pipeline." > [Introduction. The paper goes on to estimate a penalty > > around 7 to 9 % in general GHC code.] > The cost model here makes sense if ... Thanks Wren. Is that 7 to 9 % figure unduly alarmist? (It is consistent with Milan's benchmarking.) For example would strictifying or inlining have much greater benefits than worrying about constructors? And it only affects processor-intensive applications(?) > ... > Regardless of how GHC does things, those basics of branch > prediction and primop ordering will remain the same. ... > In practice GHC does the naive thing of ordering branches > to be in order of declaration in the data type definition. > This is good in as much as it doesn't matter how users > textually order their case analyses, since GHC will > reorder them. ... > ...the order of data constructors in a data type's definition > is also used for other magic, like deriving Ord. ... Hmm, I'd hardly describe derivng Ord as "magic". It's what the language report says [Chapter 11]. > Really, we'd like to make GHC smarter here about > how it orders [case branchng code]; > but that gets complicated very quickly. I can see that. I gave some possible rules of thumb in an earlier message. (In particular, recursive constructors are more likely.) > ... noone other than me seems to care very much. ... I guess not many know. We kinda expect GHC will be much smarter than we could achieve by hand-crafting the object code. Those who could write assembler code must be dying out ;-) Judging by the 2006 paper, part of the difficulty seems to be that the C code GHC generates is none too idiomatic for what a C optimiser is tuned for. AntC

1 0

Fwd: Executable runs but dynamic linking fails within ghci
by Ryan G 25 Aug '16

25 Aug '16

I'm working with a GUI library and I can get everything to work when I run my executable. When I try to call my gui function within ghci, it crashes with: user error (unknown GLU entry gluOrtho2D). I'm on Arch running ghc version 7.10.3. The GLURaw maintainer could reproduce this and added some insight I can reproduce this both with LTS Haskell (based on GHC 7.10.3) and > Stackage nightly (based on GHC 8.0.1) on Ubuntu 16.04, too. This is somehow > related to GHCi's dynamic linker, which has changed a few times in the > past, and there are still issues with it. Alas, I don't remember the > details, but perhaps you can get some answers on the haskell-cafe mailing > list. All I can say is that things worked even within GHCi at some point in > the past... [image: :wink:] > > The gory details: Given an API entry name like "gluOrtho2D", the GLURaw > package uses dlopen anddlsym to get the address of the function, see the Haskell > part > <https://github.com/haskell-opengl/GLURaw/blob/2fbff384e9637e1c1763c65a5f843…> and > the C part > <https://github.com/haskell-opengl/GLURaw/blob/2fbff384e9637e1c1763c65a5f843…>. > For some reason, dlsymdoesn't find the GLU entries when running under > GHCi, while the compiled version does. > Any help is appreciated

1 0

Stack and Circle CI
by Nicola Gigante 25 Aug '16

25 Aug '16

Hi all, has any of you had any success testing haskell projects on CircleCI with a setup that involved Stack? CircleCI seems to directly support haskell by specifying the version of GHC but I wanted my dependencies and tests to be handled by Stack also on the testing machines, since it is my main development tool. I’m also new to Circle CI in particular, although I used Travis in the past. I’ve tried collecting some example files but it seems to have problems with the first ‘stack build’ phase since I see no output in the online console. My circle.yml file: dependencies: cache_directories: - "~/.stack" pre: - wget https://github.com/commercialhaskell/stack/releases/download/v0.1.2.0/stack… -O /tmp/stack.gz - gunzip /tmp/stack.gz && chmod +x /tmp/stack - sudo mv /tmp/stack /usr/bin/stack override: - stack setup - stack build test: override: - stack test Anybody? Thanks. Greetings, Nicola

3 3

ANN: Bookkeeper
by Julian Arni 24 Aug '16

24 Aug '16

I was playing around with GHC 8 yesterday, and ended up writing another extensible records library: https://hackage.haskell.org/package/bookkeeper And a blog post about it: https://turingjump.com/blog/bookkeeper/ I hope someone finds this useful! -- Julian K. Arni Haskell Consultant, Turing Jump https://turingjump.com

3 3

cat as banana In AOP
by cutsea110 24 Aug '16

24 Aug '16

Hi,all I'm studying `Algebra of Programming' written by Prof. Richard Bird. My question is for section 3.5 "Concatenation and currying > Exponentials". In page 74, he said ``` cat = (| curry ([outr, cons] . (id+id x apply) . (id+assocr) . distl) |) ``` where (| ... |) means banana operator. But I guess this left hand side `cat' is typo of `ccat` or `curry cat`? I think this is reasoned below. ----------------------------- cat . (alpha x id) = [outr, cons] . (id + id x cat) . phi <= page 73 start expr (maybe this is from equation (3.6)) = {- Theorem 3.1 precondition -} cat = apply . ( (| curry (h . G apply . phi |) x id) ----- (A) = {- on the other hand, exponential's universal property : g = curry f == apply . (g x id) = f -} cat = apply . ((curry cat) x id) ----- (B) = {- from (A) and (B) -} (curry cat) = (| curry (h . G apply . phi |) ----------------------------- This result is curry cat = (| curry ( [outr, cons] . (id + id x apply) . (id + assocr) . distl) |) not cat = rhs(above). How about this?

1 0

Rigid type variables and their role in type checking
by Morten Olsen Lysgaard 24 Aug '16

24 Aug '16

I am making a toy compiler for a polymorphic lambda calculus working of Stephen Diehls excellent Write You a Haskell [1]. I would like to add explicit type annotations to the language, eg. type signatures for functions, but yesterday stumbled over a nut I still haven't been able to crack. The problem is with the semantics of programmer specified type annotations, type variables contained in those signatures and how they interact with the type checker. First off, the WYAH type inference algorithm is a text-book implementation of Hindley-Milner algorithm. It is designed to take a program without any explicit type information, and if type checking succeeds, it outputs the types of every part of the AST. This works fine, the issue surfaced when I added explicit type annotations to the AST. Lets say I have the function: foo1 :: a -> a foo1 x = x The inferred type of `foo1` is `foo1 :: t -> t`, when unified with the annotated type, `a -> a`, the substitution [t = a] is found. Everything works out, as it should. Now consider: foo2 :: Int -> Int foo2 x = x The inferred type of `foo2` is `foo2 :: t -> t` when unified with the annotated type, `Int -> Int`, a substitution [t = Int] is found. Everything works out, as it should. Lastly consider: foo3 :: a -> Int foo3 x = x The inferred type of `foo3` is, again, `foo3 :: t -> t`, when unified with the annotated type, `a -> Int`, we find that `t` must have the same type as `a`, and `t` must be of type `Int`, thus `t = a = Int`. Everything works out!? This is of course not intended behavior, the type annotation on foo3 is horribly wrong, and is blatantly lying about the actual type of the function. When I found this my first instinct was to check how the Haskell compiler would check this function. I found that Haskell complains: Couldn't match expected type `a' with actual type `Int' `a' is a rigid type variable bound by the type signature for foo3 :: a -> Int at foo3.hs:1:9 As far as I understand, Haskell has the notion of a rigid type variable, which my compiler is missing, I am also guessing that these rigid type variables have different rules with respect to unification? Where can I read more about these strange things? I have been trying to form the rules for unification from my intuition about Haskell type checking, but still haven't grasped the whole story, eg. how does one decide if the rigid type variable can be "specialized" or not. In `foo2` it is ok to specialize `a` into `Int`, but in `foo3`, this is not ok. I am struggling to see the underlying rules for this, and would gladly appreciate any pointers to enlightenment! Bonus question! Given the function: foo4 :: a -> a foo4 x = -(x :: Int) The inferred type of `foo4` is `foo4 :: Int -> Int`. When unified with the annotated type, `a -> a`, the substitution [a = Int] is found, everything checks out! >From intuition we know that the type annotation for `foo4` is "to general", that is, `generalness(Int -> Int) < generalness(a -> a)`, but how does one actually express that in code? That is, what is the algorithm that lies behind the function `generalness`? [1] http://dev.stephendiehl.com/fun/

2 1

Re: [Haskell-cafe] How to report builds...?
by Christopher Howard 24 Aug '16

24 Aug '16

On 08/24/2016 12:01 AM, Daniel Trstenjak wrote: > > On Tue, Aug 23, 2016 at 09:32:56PM -0800, Christopher Howard wrote: >> Hi list. Hackage cannot build my package, because for some reason it >> will only use base-4.9.0.0, which does not satisfy the dependencies of >> some of my dependencies. So, I was trying to figure out how to report my >> own builds. However, when I use the "cabal report" command, cabal take >> my username and password, and then (so far as I can tell) does nothing. >> I tried increasing the verbosity, as well as upgrading to the latest >> version of cabal, but this did not work. And I can seem to find the >> documentation for this feature. Please advise. > > But the first thing you could try is to call cabal with the '--allow-newer' > option, which allows newer library versions then specified by the > constraints. This will only work if the newer library versions don't > containt breaking changes, so it's just a way to get going for the > moment but no real solution. > > About the reporting, there's no other way then to contact every single > developer of the breaking libraries. > Well, I know the reason it cannot build with base-4.9.0.0: My library is fully compatible with base (>=4.6 && <4.10), but it depends on the Gloss library (>=1.7 && <1.10). I cannot use Gloss 1.10, because Gloss 1.10 has a breaking API change on one of the Gloss functions I use in my library, which I could only get around if I used a lot of conditional code, which I haven't done yet. However, only Gloss 1.10.* is compatible with base-4.9.0.0. http://hackage.haskell.org/package/mars http://hackage.haskell.org/package/mars-0.2.1.0/reports/ Hackage, it is seems, will only try building with base-4.9.0.0, rather than reverting to an earlier version and compiler. The package builds just fine on my system, using an earlier base and compiler. So, I guess the question is, do I have to further restrict the dependencies of my library (to exclude 4.9.0.0) just because one of my dependencies cannot handle that version? -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu)

2 1

How to report builds...?
by Christopher Howard 24 Aug '16

24 Aug '16

Hi list. Hackage cannot build my package, because for some reason it will only use base-4.9.0.0, which does not satisfy the dependencies of some of my dependencies. So, I was trying to figure out how to report my own builds. However, when I use the "cabal report" command, cabal take my username and password, and then (so far as I can tell) does nothing. I tried increasing the verbosity, as well as upgrading to the latest version of cabal, but this did not work. And I can seem to find the documentation for this feature. Please advise. -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu)

2 1

Proposal: (.:) operator in base.
by Alex Belanger 23 Aug '16

23 Aug '16

Hi, Some of you might be familiar with (.:) = (.) . (.). It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d It allows the composition of two functions, the first one, accepting one operand, and the second, two operands. This appears to be a very common pattern, referenced a bit everywhere, almost always defined on lambdabot and found in multiple codebases in the wild. I'd like the know the general sentiment about this operator, as well as how its inclusion in base, probably Data.Function, would be perceived before I actually try to make it happen. Cheers, Alex (nitrix).

7 8

Re: [Haskell-cafe] Proposal: (.:) operator in base.
by David Feuer 23 Aug '16

23 Aug '16

And also sometimes wrong. I don't really understand why, but sometimes eta *expansion* is important when working around RULES. On Aug 23, 2016 5:42 AM, "Alan & Kim Zimmerman" <alan.zimm(a)gmail.com> wrote: Suddenly the eta reduce hlint warning becomes much more important. Alan On 23 Aug 2016 11:22 a.m., "Tom Ellis" <tom-lists-haskell-cafe-2013@ jaguarpaw.co.uk> wrote: > *Very* interesting. Here is the key section of the GHC users guide: > > GHC will only inline the function if it is fully applied, where “fully > applied” means applied to as many arguments as appear (syntactically) > on > the LHS of the function definition > > That this is a good heuristic is *extremely* counterintuitive to me. I > would have supposed that being more explicit, for example > > {-# INLINE (.) f g #-} > > to inline on all static applications of at least two arguments would have > been a much clearer way to communicate this message. > > What's the rationale behind the current behaviour? > > Tom > > > On Tue, Aug 23, 2016 at 09:56:25AM +0100, Matthew Pickering wrote: > > I think the point which no-one has articulated yet is that the > > source-level arity of (.) affects whether GHC will decide to inline it. > > > > Only fully saturated applications are inlined > [...] > > > > On Tue, Aug 23, 2016 at 8:33 AM, Tom Ellis > > <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> wrote: > > > On the contrary, they're exactly the same (on GHC 7.6.3): > > > > > > module Foo where > > > > > > comp1 f g x = f (g x) > > > > > > comp2 f g = \x -> f (g x) > > > > > > > > > % ghc -O0 -dsuppress-all -fforce-recomp -no-link -ddump-prep > test.hs > > > [1 of 1] Compiling Foo ( test.hs, test.o ) > > > > > > ==================== CorePrep ==================== > > > Result size of CorePrep = {terms: 24, types: 36, coercions: 0} > > > > > > comp2 > > > comp2 = > > > \ @ t_aeU @ t1_aeV @ t2_aeW f_sfz g_sfy x_sfx -> > > > let { > > > sat_sfI > > > sat_sfI = g_sfy x_sfx } in > > > f_sfz sat_sfI > > > > > > comp1 > > > comp1 = > > > \ @ t_af5 @ t1_af6 @ t2_af7 f_sfG g_sfF x_sfE -> > > > let { > > > sat_sfJ > > > sat_sfJ = g_sfF x_sfE } in > > > f_sfG sat_sfJ > > > > > > (the same holds for -O2, if you compile them separately) > > > > > > On Tue, Aug 23, 2016 at 05:19:38PM +1000, Ben wrote: > > >> At the semantic level of "does my program compute correct results" > they're > > >> identical. At the operational level of "how fast does my program run" > > >> they're different. > > >> > > >> > > >> On August 23, 2016 5:09:19 PM GMT+10:00, Tom Ellis < > tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> wrote: > > >> >On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: > > >> >> (.) f g = \x -> f (g x) > > >> >> > > >> >> vs: > > >> >> > > >> >> (.) f g x = f (g x) > > >> >> > > >> >> has ramifications, though it's fairly easy to guess which one of > > >> >those > > >> >> two will be most performant. > > >> > > > >> >Are these not synonyms? What is the meaning of > > >> > > > >> > fargs var = expr > > >> > > > >> >if not > > >> > > > >> > fargs = \var -> expr > > >> > > > >> >? > _______________________________________________ > 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. _______________________________________________ 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