- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 16
by Anthony Clayden 17 Sep '21

17 Sep '21

>> "The seeds of your confusion are very evident from your message". > The seeds of your unsubstantiated assumptions about me are very evident from yours. OK Michael, I can see I'm not helping. I'll stop. On NLP (a topic on which I have some expertise), I'll save you time in your search: Haskell is not suitable. Use a NLP tool. Programming languages and their semantics are so unlike natural languages as to be useless. I found your "primer for the lexical semanticist" to be full of strained and unhelpful analogies. I was surprised it omitted mention of Montague Grammar -- which draws from Lambda calculus/Combinators, and would be the obvious go-to _if_ Haskell were to be applicable. On unsubstantiated assumptions: > I started programming at 15. Me too. (Dartmouth BASIC on a teletype over a dial-up line to a timeshare service.) > It's been a very rare year, even after leaving the software profession, when I didn't write at least some code, learning new things in the process. Me ditto. > Which means I've been looking at programming languages and how to implement things at the most appropriate level of abstraction possible for just a few months shy of fifty years. For me, a few months over fifty years. (BTW nothing you've said persuades me away from recommending the best way to learn Haskell is via Lambda-calculus.) AntC

1 0

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

17 Sep '21

Hi David, The Foldable Laws are here https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-F… In the Data-Foldable doco. (There's a menu entry on the sidebar, or text search.) The Data-Traversable doco has only the Traversable Laws. > I'm not talking about whether they're first or last. They're currently not part of the class documentation *at all*. They're only in the Data.Traversable documentation.

1 0

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 17 Sep '21

17 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 14 Sep '21

14 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