- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Haskell reference documentation, laws first or laws last?
by Anthony Clayden 17 Sep '21

17 Sep '21

Hi Viktor, really this is a quite different q than the thread talking about a learner's experience. You're writing deeply-technical detail not at all aimed at beginners. There's a very broad range of reasons and prior knowledge for readers of Library docos. But I disagree with this: > The beginner to intermediate users will be using the library and existing instances for some time before they start to write their own instances. I'll want to write an instance of Foldable as soon as I've declared my datatype, won't I? Or do you expect me to be folding only over Lists? Speaking for myself, if I want to understand a function, I look first at its type then its source definition. The Laws for the particular Foldable example I don't understand at all. I'd say: hide those Laws as far away as possible. In fact, since the blasted FTP re-organisation of that library, I've more or less given up. Too hard/too abstract/too much Category Theory. What's an `Endo`? Thank you for your efforts to document. I expect there's someone you're helping. Not me. I don't think it's that the style "sucks". This style and content is enough for me: https://www.haskell.org/hugs/pages/libraries/base/Data-Foldable.html > Of course the conjectured users who might most benefit from not being intimidated by being exposed to laws before they're ready to understand them might not be present on this forum... I've gone well beyond the point of being intimidated by Category Theorists. I find they're doing a splendid job of putting people off getting to love Haskell as I used to. If you want to tell me off for speaking out of turn, go ahead. (But this forum is the cafe, perhaps this particular discussion should be on glasgow-haskell-users?) AntC On Thu, Sep 16, 2021 at 06:51:42PM -0400, David Feuer wrote: >* The last time I went to look at the laws it took me a couple minutes to *>* find them. I use them to write instances. Pretty important, IMO. * I agree the laws are important to document, I just don't think they belong at the top of the module. The beginner to intermediate users will be using the library and existing instances for some time before they start to write their own instances. If more modules adopt something like the style of the new Data.Foldable, experienced users will know to look for the laws at the end, if not still present at the top of the module. Of course perhaps the community would prefer the original Laws first format, I'm fine with that emerging as the consensus. Perhaps worthy of a separate thread (made it so). Of course the conjectured users who might most benefit from not being intimidated by being exposed to laws before they're ready to understand them might not be present on this forum... --

1 0

Bundle patterns with type aliases
by Keith 16 Sep '21

16 Sep '21

Is there currently a way to 'bundle' a pattern with a type alias? And if not, could that capability be added to the PatternSynonyms GHC extension? (Is this the right place to ask, or should I be asking a GHC list?) --Keith Sent from my phone with K-9 Mail.

3 4

Mixed Fraction data type
by Galaxy Being 15 Sep '21

15 Sep '21

I'm looking at Sandy Maguire's _Thinking With Types_ and he's talking about the cardinality of types. He introduces the product type data MixedFraction a = Fraction { mixedBit :: Word8 , numerator :: a , denominator :: a } How is this a type for holding mixed fractions such as 5-1/2? ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

2 3

Comment on "The Historical Futurism of Haskell" by Andrew Boardman
by Dominic Steinitz 15 Sep '21

15 Sep '21

> On 12 Sep 2021, at 13:00, haskell-cafe-request(a)haskell.org wrote: > > In particular, I am a mathematician/statistician working in evolutionary > biology. I work with multivariate distributions (hardly any of those are readily > available on Hackage), I work with a lot of random numbers (the support for > random sampling is mediocre, at best; 'splitmix' is standard by now but not > supported by the most important statistics library of Haskell), I work with > numerical optimization (I envy Pythonians for their libraries, although I still > prefer Haskell because what I achieve, at least I get right), I work with Markov > chains (yes, I had to write my own MCMC library in order to run proper Markov > chains), I need to plot my data (there is no superb standard plotting library > available in Haskell). By now, I do maintain library packages providing answers > to some of these problems, but it was (and is) a lot of work. I have to take issue with your statement about random sampling. I think we have a really good story with random numbers now. They are of high quality and fast. R and possibly Python and Julia by comparison still use Mersenne Twister, of lower quality, slower and without a good story for generating independent sequences for parallel computations. I maintain random-fu (sampling from distributions) and using the new random number generator it is now several times (x4?) faster than it was. Conceivably it could be made even faster. Please give details on where you think we can improve and better still contribute your own improvements :-) In terms of MCMC, I think Jared Tobin wrote some libraries but I don’t think they are maintained. I maintain an SMC library but I don’t know how much use it gets. Tom Nielsen, Henrik Nilsson and I wrote Haskell “bindings” for Stan: https://nottingham-repository.worktribe.com/output/1151875/getting-more-out…. It would be a lot of work to e.g. re-create Stan in Haskell natively. I agree about plotting but inline-r makes it possible to use ggplot in R via Haskell which makes things like drawing maps with reasonable projections relatively straightforward. More generally, I think we have a good set of bindings for the ODE solver library SUNDIALS and also for other numeric libraries (e.g. LAPACK and BLAS). The problem we have is not enough hands working on such things. I now sadly return to programming in Julia. PS - there is probably more I could say on numerical stuff in Haskell but the above already looks like “stream of consciousness”. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch

2 3

Trouble with asinh (c calls with Doubles) in Windows
by David James 15 Sep '21

15 Sep '21

Hello all – I’m trying to debug a problem with asinh in Windows. On Linux (Ubuntu 18.04.5 LTS) running GHC 8.10.7, I get (I think correctly): GHCi, version 8.10.7: https://www.haskell.org/ghc/ :? for help Prelude> asinh 1.7976931348623157e308 710.4758600739439 But on Windows I get: GHCi, version 8.10.7: https://www.haskell.org/ghc/ :? for help Prelude> asinh 1.7976931348623157e308 NaN My understanding is that, since commit c6f4eb4f8<https://gitlab.haskell.org/ghc/ghc/-/commit/c6f4eb4f8bc5e00024c74198ab9126b…> (released in GHC 8.8.1, I think), asinh is defined as a primop that just calls the c asinh function, so I tried the following code: In Main.hs: {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE CApiFFI #-} module Main (main) where import Foreign import Foreign.C.Types foreign import ccall unsafe "math.h asinh" c_asinh :: Double -> Double foreign import ccall unsafe "CAsinh.c testFn" c_testFn :: IO () main :: IO () main = do putStrLn $ "asinh 1.7976931348623157e308 = " ++ show ( asinh 1.7976931348623157e308) putStrLn $ "c_asinh 1.7976931348623157e308 = " ++ show (c_asinh 1.7976931348623157e308) putStrLn "Calling c_testFn..." c_testFn In CAsinh.c: #include <stdio.h> #include <math.h> void testFn () { printf ("in testFn\n"); printf ("asinh(1.7976931348623157e308) = %f\n", asinh(1.7976931348623157e308)); double x = 1.7976931348623157e308; printf ("asinh(x) = %f\n", asinh(x)); } In Linux, this all works fine: asinh 1.7976931348623157e308 = 710.4758600739439 c_asinh 1.7976931348623157e308 = 710.4758600739439 Calling c_testFn... in testFn asinh(1.7976931348623157e308) = 710.475860 asinh(x) = 710.475860 But on Windows I get weird results: asinh 1.7976931348623157e308 = NaN c_asinh 1.7976931348623157e308 = NaN Calling c_testFn... in testFn asinh(1.7976931348623157e308) = 710.475860 asinh(x) = -1.#IND00 The primop call from Haskell to asinh and the FFI call to c_asinh give the same (incorrect) result, as I expected. But the first call to asinh from the c testFn gives the correct result. So why is that different to the FFI call from Haskell? And why doesn’t the second call from testFn return the right result? I also tested on 9.0.1 on Windows, with a slightly different result for the final asinh: ... asinh(x) = nan I’ve investigated the things I can think of (different foreign declarations, size of double being different, checking the code in cpp.sh<http://cpp.sh/>), but can’t find an explanation. Am I doing something silly? Is this a (known) bug? Note that on Windows, values up to asinh 1.3407807929942596e154 work correctly. (As a little background: I was trying to implement the Kahan<https://people.freebsd.org/~das/kahan86branch.pdf> functions to give the correct branch cuts for complex trig functions, something I think the current Haskell implementation doesn’t do correctly. These depend on asinh, etc, on RealFloat numbers). Thanks very much for any help, David. *

4 6

Typeable convenience class
by David Feuer 15 Sep '21

15 Sep '21

Occasionally it's useful to get a little information about a type's constructor (especially its name, module, or source package), without needing a Typeable instance for the type itself. I came up with this rather simple way, but I'm wondering if something like this already exists on Hackage. #if __GLASGOW_HASKELL__ < 710 {-# language OverlappingInstances #-} #endif ... import Data.Typeable class OuterTypeable a where -- | Get the 'TypeRep' corresponding to the outermost constructor -- of a type. getConTR :: proxy a -> TypeRep #if __GLASGOW_HASKELL__ >= 708 instance # if __GLASGOW_HASKELL__ >= 710 {-# OVERLAPPING #-} # endif OuterTypeable f => OuterTypeable (f a) where getConTR _ = getConTR (Proxy :: Proxy f) instance Typeable a => OuterTypeable a where getConTR = typeRep #else -- Before GHC 7.8, we didn't have polykinded Typeable, so things were -- rather less nice. instance Typeable a => OuterTypeable a where getConTR _ = typeOf (undefined :: a) instance Typeable1 p => OuterTypeable (p a) where getConTR _ = typeOf1 (undefined :: p a) [...] instance Typeable7 p => OuterTypeable (p a b c d e f g) where getConTR _ = typeOf7 (undefined :: p a b c d e f g) #endif

1 0

Re: [Haskell-cafe] Comment on "The Historical Futurism of Haskell" by Andrew Boardman
by Rishiyur Nikhil 14 Sep '21

14 Sep '21

This thread seems to be a mixture of (A) the original topic (about broad obstacles to Haskell adoption) and (B) technical details about particular libraries that came up in the conversation that may not be of immediate interest to people following (A). For people discussing (B), kindly change the subject line of your reply to be more specific to (B). Thanks, Nikhil

1 0

[ANN] Core Libraries Committee Elections
by Emily Pillmore 13 Sep '21

13 Sep '21

Dear Haskell Community, The Core Libraries Committee is seeking new members! As detailed in recent updates (see: https://discourse.haskell.org/t/state-of-the-core-libraries-committee-updat… ), we put out an internal call to discuss restructuring the CLC to better meet the needs of the community. In particular, we are in the planning stages of writing the new process, and are seeking **2** new members who, as part of their standard CLC duties, get to participate in its construction. ## Who should apply? Anyone who meets the following criteria should apply: 1. Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (2 to 3 per month), and *sustain* this for their term in a healthy manner. 2. Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the new Github-based CLC process on a semi-frequent basis (2 to 3 per month). 3. Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. 4. Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room - quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. This election is particularly special due to the fact that our new members will have the chance to help shape process for new generations of the CLC to come, and can take ownership from the ground up so to speak. This means that we can help shape a process that works better for us as modern Haskell developers, and help the CLC become a better fit for the community's needs. ## How can I apply? To apply for one of these positions, send an email to the CLC email address ( core-libraries-committee(a)haskell.org ) that consists of the following data: 1. The header "CLC Election September 2021 - <your name>" 2. Why you think you're a good fit given the above criteria 3. If applicable, please point us to some code you've written ## When will elections be decided? Please note the following dates: 1. Election submissions open: Sept 13 2. Election submissions close: Sept 20 3. Election outcome announced: Sept 27 Cheers, Emily - on behalf of the CLC

1 0

Comment on "The Historical Futurism of Haskell" by Andrew Boardman
by Dominik Schrempf 13 Sep '21

13 Sep '21

Hi! I am referring to the impressive talk/show/thought-provoking message about "The Historical Futurism of Haskell" delivered by Andrew Boardman at the Haskell Love Conference. I am not sure if I am allowed to link to the talk myself, since it is password protected, and was part of a conference. Maybe this can be done by the conference organizers, or by Andrew himself, if they please. In summary, and please add your comments or correct me, Andrew discusses that we truly believe that Haskell --- as a statically typed, lazy, pure, and functional language -- is an incredibly powerful tool, that should be made available to everybody now and for the next thirty years. However, he argues that this power is hard to access because we have a lot of "adequate" tooling for a fantastic language. He adds that we need superb tooling in order for "beginners to learn faster, and experienced programmers to accelerate productivity". He refers to overhauling programming environments to reflect data flow across and within functions and to "setting higher standards" for ourselves so that we finally "lift ourselves out of the pit of adequacy". He also asks whether it is really necessary to be in "crisis mode" to invest into fundamental changes of the ecosystem (escalation of commitment). I deeply agree, and wanted to thank Andrew for his talk. Personally, to me it seemed that Andrew was more referring to the programming environment than to the set of available libraries, although this may not have been his intention. I wanted to express that in my opinion, and in order to drive Haskell forward, we need a qualitative, reliable, performant, and well maintained "standard" library. Haskell has many "adequate" libraries but few superb ones. And while I understand that the immense advantages of being an open source community also come at a cost: a lot of work we do in our free time, because we have limited funding for improving libraries or development environments. Many libraries are maintained by one individual who may have the time and resources (or not) to look at standing issues or possibilities for improvements. In particular, I am a mathematician/statistician working in evolutionary biology. I work with multivariate distributions (hardly any of those are readily available on Hackage), I work with a lot of random numbers (the support for random sampling is mediocre, at best; 'splitmix' is standard by now but not supported by the most important statistics library of Haskell), I work with numerical optimization (I envy Pythonians for their libraries, although I still prefer Haskell because what I achieve, at least I get right), I work with Markov chains (yes, I had to write my own MCMC library in order to run proper Markov chains), I need to plot my data (there is no superb standard plotting library available in Haskell). By now, I do maintain library packages providing answers to some of these problems, but it was (and is) a lot of work. Finally, I want to thank all library developers for their impressive work, thank you! And still, I think it is not enough. In my opinion, these are all examples where Haskell needs to improve if we want to broaden the adoption among the general public. Do we have the resources? Thank you! Dominik

4 4

Virtual Haskell CoHack on Sep 25
by Chris Smith 12 Sep '21

12 Sep '21

For the second time, I'm hosting a virtual Haskell CoHack on September 25. If you've wanted to meet new Haskellers, give or hear lightning talks, and hack together on Haskell projects, this is your chance. Sign up at https://www.meetup.com/NY-Haskell/events/280727563/ The event will be held via Zoom. I've tried to time it to be reasonable for people across the Americas and Europe. Sadly, time zones cannot accommodate everyone. :( But if you can, please consider coming!

1 0