- Libraries - Haskell.org

Re: Proposal: Make Semigroup and Monoid instances for Data.Functor.Compose
by Ryan Scott 26 Jul '19

26 Jul '19

Hi, You may find the discussion at https://mail.haskell.org/pipermail/libraries/2018-February/028571.html interesting. The summarized version of that post is that Data.Functor.Compose was originally brought over from the transformers library, which adheres to a very Haskell98 mindset in its design. In particular, the maintainer of transformers would likely not have added the Semigroup or Monoid instances you propose, since they require the FlexibleContexts language extension. This explains why there exists an `instance (Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a)` and not an `instance Eq (f (g a)) => Eq (Compose f g a)`, among other things. Of course, Data.Functor.Compose now lives in the base library, not transformers, so we need not prescribe to the same design philosophy. I don't feel too strongly about the issue, so if other people feel like adding Semigroup/Monoid instances that require FlexibleContexts is a good idea, I could get on board with that. What do others think? Ryan S.

4 3

Proposal: Make Semigroup and Monoid instances for Data.Functor.Compose
by Keith 25 Jul '19

25 Jul '19

With the Monoid 'First' and 'Last' newtypes going away, it would be nice to have equivalent Functor and Applicative instances. This works if Compose uses its components' instances: instance Semigroup (m (n a)) ⇒ Semigroup (Compose m n a) where Compose mnx <> Compose mny = Compose (mnx <> mny) instance Monoid (m (n a)) ⇒ Monoid (Compose m n a) where mempty = Compose mempty –Keith -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

Re: Proposal: composition util for Maps
by Johannes Waldmann 23 Jul '19

23 Jul '19

+0.9 we can have it > composition :: Ord b => Map b c -> Map a b -> Map a c > composition bc ab = flip mapMaybe ab $ flip lookup bc > Which has O(|ab| * log |bc|) performance. The given implementation traverses all of ab even if bc is empty. We could detect this. But for |bc| = 1, there is no work-around? So, O(|ab| * max(1, log |bc|)) ? I think this could only be improved if we had a representation of the inverse of ab as well. I don't think it should be computed on-the-fly, as in https://github.com/haskell/containers/issues/647#issuecomment-504798611 This would better be handled in a proper library for relations ( https://hackage.haskell.org/package/relation has this data type, but does not have composition?) bike-shedding the name and type: * composition vs. compose: the library usually favours the noun: intersection (not intersect), difference (not subtract) * order of arguments: mathematically speaking, it is of course very wrong, but it's consistent with the wrongness of (.) ... - J.W.

3 2

ANNOUNCE: lens-family 2.0.0 anniversary edition!
by roconnor＠theorem.ca 20 Jul '19

20 Jul '19

In celebration of the 10th anniversary of Twan van Laarhoven's seminal blog post ``CPS based functional references''[1], I am releasing version 2.0 of lens-family[2] and lens-family-core[3] packages. This new release continues to explore the design of Van Laarhoven style optics with new support for adapters, grates, grids[4], and prisms. To bring support to these new optics necessarily means moving a little further away from syntactic compatibility with Kmett's lens library. In particular, lens-family's 'under' is unrelated to Kmett's lens library's 'under' combinator. Nonetheless the 'under' combinator plays a crucial role in lens-family as a dual to the 'over' combinator and this naming is hard to resist despite the conflict. This new version comes with some minor incompatibilities with the version 1.2 library that may require user updates. See <https://hackage.haskell.org/package/lens-family-2.0.0/changelog>. [1]<https://www.twanvl.nl/blog/haskell/cps-functional-references> [2]<https://hackage.haskell.org/package/lens-family-2.0.0> [3]<https://hackage.haskell.org/package/lens-family-core-2.0.0> [4]A grid is an optic that is both a grate and a traversal. -- Russell O'Connor <http://r6.ca/>

4 5

Taking over `rungekutta`
by Marco Zocca 16 Jul '19

16 Jul '19

Hi all, I'd like to take over maintainership of this library https://hackage.haskell.org/package/rungekutta Its latest upload was in 2009 and it doesn't have a listed version control repository. I think it's safe to assume it's abandoned. The listed author email is unreachable and I cannot find an alternative email to contact the author. Thank you, Marco

1 0

Cayenne Source Code
by Andrew Martin 09 Jul '19

09 Jul '19

I just read through Lennart's paper on Cayenne, which was written in Haskell. It would be informative for me to look at the source code for a simple dependently typed language like this. (The paper claims the typechecker is only around 5000 LoC.) However, I cannot find the source code anywhere. Has it been devoured by the cruel jaws of the ephemeral web, or does someone out there still have a copy of it? -- -Andrew Thaddeus Martin

3 3

RE: [GHC DevOps Group] Making GHC's fast release cadence work
by Simon Peyton Jones 09 Jul '19

09 Jul '19

It seems to me that both questions are sensible ones: 1. What should GHC’s release cadence be? For example, would annual be better than semi-annual? Herbert and Michael both think so, and they know a thing or two. I’d love to hear from more people on this question. 1. When we do make a release, whenever that is, how we can work most productively with library authors, so that the release comes out in a timely way? This was Ben’s original question, and it applies regardless of cadence. Simon From: Ghc-devops-group <ghc-devops-group-bounces(a)haskell.org> On Behalf Of Michael Snoyman Sent: 02 July 2019 05:54 To: Herbert Valerio Riedel <hvriedel(a)gmail.com> Cc: David Feuer <david.feuer(a)gmail.com>; ghc-devops-group(a)haskell.org; Ashley Yakeley <ashley(a)semantic.org>; Judah Jacobson <judah.jacobson(a)gmail.com>; David Terei <code(a)davidterei.com>; Herbert Valerio Riedel <hvr(a)gmail.com>; Haskell Libraries (libraries(a)haskell.org) <libraries(a)haskell.org> Subject: Re: [GHC DevOps Group] Making GHC's fast release cadence work On Tue, Jul 2, 2019 at 12:12 AM Herbert Valerio Riedel <hvriedel(a)gmail.com<mailto:hvriedel@gmail.com>> wrote: On Mon, Jul 1, 2019 at 8:09 PM Ben Gamari <ben(a)well-typed.com<mailto:ben@well-typed.com>> wrote: > Naturally, delays like this make it hard for GHC to maintain its faster release cycle > ... > How do you think we might speed up this process? IMO You're asking the wrong question. This seems based on a premise that everyone agreed with a faster release cycle... to me the downsides on the ecosystem and infrastructure of a faster release churn significantly outweight the modest benefit some people might perceive; and the issue's we've been observing (not only boot libraries, but also the 10k packages on Hackage) with the overspeeded release cycle are IMO a sign that we're moving faster than the ecosystem can accommodate. Just because GHC HQ managed to optimize their release processes (and I have to say, at the expense of the release quality -- GHC 8.6.5 was the first major release since GHC's beginning to require five attempts -- and I have to note that this results in annoying busy work for GHC packagers like myself) doesn't mean that everyone else has the time and energy to adapt to this new order as well. +1

10 15

Proposal: add HasCallStack for all partial functions in base
by LuoChen 08 Jul '19

08 Jul '19

Motivation Partial functions in base (especially Prelude) often cause runtime errors and is hard to locate. (here <https://gist.github.com/luochen1990/6fcbb0fa4c0c7caa1b242188eb586d1f> is a document about the concept of totality and partial function, ignore this if you are familiar with them) For example, consider the following piece of code: import GHC.Stack foo :: HasCallStack => [Int] -> Int foo xs = last xs + 1 xs :: [Int] xs = [] main :: IO () main = do print $ foo xs In this case, the error message will tell nothing about foo, and the HasCallStack constraint is totally helpless, because the call stack is cut off by the call to last which without HasCallStack constraint. My current workaround is define my own wrapper functions with HasCallStack constraint for some mostly used partial functions to make them traceable, and use the wrapper (the traceable version) whenever I need them. e.g. last' :: HasCallStack => [a] -> a last' xs = case xs of [] -> error "abuse last"; _ -> last xs So, IMHO, if our goal is to make errors in haskell traceable, then *only providing HasCallStack mechanism is not enough, we have to provide traceable base package and prelude at the same time*. Further more, all untraceable partial functions are considered to be harmful, and should not be exported by any package. Because an improper call to an untraceable partial function will cut off the call stack, and here is a demonstration about that <https://gist.github.com/luochen1990/94179a2492ff7d1ca45153645f1bb449>. On the other hand, is it ever necessary for us to add HasCallStack for a total function? Or we can ask, is it possible that a call to a total function cause runtime error? Maybe it’s a NO, since a total function will also crash when the machine is Out Of Memory, but that is also the only situation I can find out. So I suggest that we add HasCallStack constraint only for partial functions, and IMHO this could be a good balance for better debugging experience and less runtime overhead. Proposal 1. add HasCallStack constraint for all partial functions in base package 2. suggest all programmers to add HasCallStack constraint for their exported partial functions when they release a package 3. provide a compiler option -fignore-hascallstack to toggle off the effect of HasCallStack constraint in case somebody need best performance Other Considerations How to get a full list of partial functions provided by the base package? I wanted to provide a full list of partial functions exported by the base package in this post, but I find it is hard, since Haskell have no totality checking mechanism like Idris have, and there are no consistent keyword like “total” or “partial” in document, so it takes a lot of work to list all the partial functions of a package by check every item manually. Maybe we can work on this list later — when it’s turned out to be worth after some discussion. Here <https://gist.github.com/luochen1990/5b7a0844701413486da595b9b997f3c2> is part of the list that I have tidied for several modules of the base package. How to encourage all package contributors to obey the rule (see proposal #2)? I don’t know, but I think there may be some other rules to obey when contributing packages. Maybe we can just add this into the list. Obviously, the final perfect solution should be let the compiler to check the totality of functions, and automatically add HasCallStack for the ones which the compiler cannot confirm it’s totality. But this seems too far away from us, since we still doesn’t have dependent type haskell yet. How to deal with recursive partial functions? Since the HasCallStack constraint affects the performance (not only because of the runtime overhead, but also it’s influence on optimization strategy), It is best not to add HasCallStack on recursive functions. In most of the cases, we can just check the input shallowly before everything start, just like how we deal with the non-recursive ones. But in some other cases, we need to go deep to recognize the invalidity of the input. A trivial solution is just perform a deep check before everything start, but the checking phase seems expensive. The best solution, IMHO, is to make the recursive part a total function, wrap the return value into Maybe or some similar things, and the partial version is just the total version combined fromJust. In this way, we avoid the single input checking phase and left the error awareing logic where it was before this translation.

9 18

Proposal: composition util for Maps
by Alexandre Esteves 07 Jul '19

07 Jul '19

In https://github.com/haskell/containers/issues/647 I proposed the following util: composition :: Ord b => Map b c -> Map a b -> Map a c composition bc ab = flip mapMaybe ab $ flip lookup bc Which has O(|ab| * log |bc|) performance. It's not particularly hard to write, but it does feel like a primitive-ish operation, and it's not obvious to me whether there's a faster implementation. Other name suggestions - (.) - chain - compose

6 6

Install GHC from source with profiling build of base
by Andrew Martin 02 Jul '19

02 Jul '19

When I build GHC from source, I can see a bunch of .p_hi files under libraries/base. This makes sense given that the default for GhcLibWays is "v p". But when I run "make install" all the profiling stuff gets stripped out: amartin@thadtop:~/.local/lib/ghc-8.9.0.20190628$ find . | grep -o '\.[^./0-9]*$' | sort -u . .a .cache .conf .d .dyn_hi .h .hi .lock .o .so .txt Not a profiling-related artifact in sight. And this local build rightfully fails to build anything with profiling turned on. So, how do I actually install the profiling builds of the wired in libraries? -- -Andrew Thaddeus Martin

1 0