- Haskell-Cafe - Haskell.org

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

Backpack: polymorphic instantation?
by Jaro Reinders 12 Sep '21

12 Sep '21

I'm playing around with backpack, trying to rewrite existing libraries. My end goal is to see if Backpack could improve the primitive library. Right now, the primitive library (in my opinion) relies too heavily on specialization of its type classes, so I think Backpack could help. However, I seem to be running into a limitation. I am wondering if it is a fundamental limitation, if perhaps there is a workaround, or if Backpack could be improved to support this use-case. Instead of primitive, I will take the simpler example: semigroup, which also shows this limitation. Let's convert the Semigroup class to a backpack signature: unit indef where signature Semigroup where import Prelude hiding ((<>)) data T (<>) :: T -> T -> T The problem is how to implement this signature with the type of polymorphic lists. It is easy to implement it for concrete lists like strings: unit string where module Semigroup where import Prelude hiding ((<>)) type T = String (<>) :: T -> T -> T (<>) = (++) It is also possible to implement it in terms of another signature: unit list where signature Elem where data A module Semigroup where import Prelude hiding ((<>)) import Elem type T = [A] (<>) :: T -> T -> T (<>) = (++) This is still problematic, because it is annoying that this new type A needs to be instantiated each time you want to use it. However, even more importantly, if I want to translate the 'PrimMonad' class to a Backpack signature then the 'ST s' instance needs a polymorphic type variable 's', which cannot be made concrete. And do note that I want the monad to be concrete for performance reasons, but the 's' parameter doesn't have to be concrete, because it is a phantom parameter anyway. And for lists making the 'a' parameter concrete also would not improve performance as far as I know. One possible way to fix this is to add a type variable in the 'Semigroup' signature, but then I think it becomes impossible to write the 'String' instance and sometimes you need more than one new type variable such as with the 'ReaderT r (ST s)' instance of 'PrimMonad'. In OCaml you can still kind of work around this problem by creating local instances inside functions. That trick still allows you to write a polymorphic concatenation function using a monoid signature (taken from [1]): let concat (type a) xs = let module MU = MonoidUtils (ListMonoid(struct type t = a end)) in MU.concat xs;; So, I'm wondering if it would be possible to "generalise" over indefinite Backpack types such as 'A' in the 'Elem' signature above or if we can at least implement something which enables the same trick that you can use in OCaml. Thanks, Jaro [1] https://blog.shaynefletcher.org/2017/05/more-type-classes-in-ocaml.html

2 4

Re: [Haskell-cafe] Backpack: polymorphic instantation?
by Daniel Díaz 11 Sep '21

11 Sep '21

Perhaps this is not what you had in mind, but we could write a signature like {-# LANGUAGE KindSignatures #-} > signature Mystery where > import Data.Kind > import Control.Monad > data MysteryMonad :: Type -> Type > instance Functor MysteryMonad > instance Applicative MysteryMonad > instance Monad MysteryMonad > instance PrimMonad MysteryMonad that reused the existing PrimMonad class. Code could depend on that signature without being tied to a concrete monad (this would make the package that has the code "indefinite"). Once we compiled the indefinite code against an actual implementation, it would be optimized as if we had used concrete types from the beginning. One problem with this solution is that it leaves out ST. If we wanted to make it work with ST, one possible hack would be to define the signature like this data MysteryMonad :: Type -> Type -> Type > instance Functor (MysteryMonad s) > instance Applicative (MysteryMonad s) > instance Monad (MysteryMonad s) > instance PrimMonad (MysteryMonad s) And then use some kind of newtype adapter with a phantom type for non-ST monads: module Mystery where type MysteryMonad = W IO > newtype W m a b = W (m b) deriving newtype (Functor, Applicative, Monad) But perhaps it would complicate things too much. On Sat, Sep 11, 2021 at 2:08 PM <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Backpack: polymorphic instantation? (Jaro Reinders) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 11 Sep 2021 11:58:26 +0200 > From: Jaro Reinders <jaro.reinders(a)gmail.com> > To: Haskell Cafe <haskell-cafe(a)haskell.org> > Subject: [Haskell-cafe] Backpack: polymorphic instantation? > Message-ID: <3fb19986-f998-61c7-8c56-482b1647e2eb(a)gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > I'm playing around with backpack, trying to rewrite existing libraries. My > end > goal is to see if Backpack could improve the primitive library. Right now, > the > primitive library (in my opinion) relies too heavily on specialization of > its > type classes, so I think Backpack could help. However, I seem to be > running > into a limitation. I am wondering if it is a fundamental limitation, if > perhaps > there is a workaround, or if Backpack could be improved to support this > use-case. > > Instead of primitive, I will take the simpler example: semigroup, which > also > shows this limitation. Let's convert the Semigroup class to a backpack > signature: > > unit indef where > signature Semigroup where > import Prelude hiding ((<>)) > data T > (<>) :: T -> T -> T > > The problem is how to implement this signature with the type of > polymorphic > lists. It is easy to implement it for concrete lists like strings: > > unit string where > module Semigroup where > import Prelude hiding ((<>)) > type T = String > (<>) :: T -> T -> T > (<>) = (++) > > It is also possible to implement it in terms of another signature: > > unit list where > signature Elem where > data A > > module Semigroup where > import Prelude hiding ((<>)) > import Elem > type T = [A] > (<>) :: T -> T -> T > (<>) = (++) > > This is still problematic, because it is annoying that this new type A > needs to > be instantiated each time you want to use it. However, even more > importantly, > if I want to translate the 'PrimMonad' class to a Backpack signature then > the > 'ST s' instance needs a polymorphic type variable 's', which cannot be > made > concrete. > > And do note that I want the monad to be concrete for performance reasons, > but > the 's' parameter doesn't have to be concrete, because it is a phantom > parameter anyway. And for lists making the 'a' parameter concrete also > would > not improve performance as far as I know. > > One possible way to fix this is to add a type variable in the 'Semigroup' > signature, but then I think it becomes impossible to write the 'String' > instance and sometimes you need more than one new type variable such as > with > the 'ReaderT r (ST s)' instance of 'PrimMonad'. > > In OCaml you can still kind of work around this problem by creating local > instances inside functions. That trick still allows you to write a > polymorphic > concatenation function using a monoid signature (taken from [1]): > > let concat (type a) xs = > let module MU = MonoidUtils (ListMonoid(struct type t = a end)) in > MU.concat xs;; > > So, I'm wondering if it would be possible to "generalise" over indefinite > Backpack types such as 'A' in the 'Elem' signature above or if we can at > least > implement something which enables the same trick that you can use in OCaml. > > Thanks, > > Jaro > > [1] > https://blog.shaynefletcher.org/2017/05/more-type-classes-in-ocaml.html > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > ------------------------------ > > End of Haskell-Cafe Digest, Vol 217, Issue 10 > ********************************************* >

2 1