- Haskell-Cafe - Haskell.org

Where to import Id from?
by David Banas 16 Oct '17

16 Oct '17

Hi all, Would someone tell me where I can import Id from, please? I’ve struck out with both Hoogle and Google searches. Thanks! -db

4 3

Re: [Haskell-cafe] haskell-cafe brown out [Was: random library]
by dominic＠steinitz.org 14 Oct '17

14 Oct '17

I get a daily digest from the mailing list and then cut out the bit that seemed relevant fwiw. Well done for caring about mailing lists :) > On 11 Oct 2017, at 17:28, Ian Zimmerman <itz(a)very.loosely.org> wrote: > > On 2017-10-11 13:50, dominic(a)steinitz.org wrote: > >>> Interesting library! Here's a link: >>> http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html >>> <http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html> >>> >>> Thomas, >>> >>> In the linked docs, there's a claim that Hash DRBG is the fastest >>> cryptographically secure RNG on Hackage. Do you have a link to the >>> benchmark results, or perhaps some updated ones? Unlike Viktor, I'm >>> interested in less secure applications, but if the performance is >>> good, it might be worth switching from the defacto random package. >>> >>> Thanks, Jonathan > >> No-one should be using the de facto random package. It is slow and >> produces surprising results. >> >> I think one of the posters suggested using mwc-random and splitting by >> using a different seed. Although mwc-random has reasonably good >> properties, there is no guarantee about how correlated the various >> streams of random numbers will be. QuickCheck uses tf-random to avoid >> such problems. There is also a version of SplitMix >> https://hackage.haskell.org/package/splitmix >> <https://hackage.haskell.org/package/splitmix> but I don’t think this >> has been heavily road-tested. >> >> But in this case, cryptographically secure randomness is required so I >> would follow Thomas’ suggestion. >> >> PS I just noticed my spellchecker changed defacto to defect! Perhaps >> AI is taking over. > > Hello, may I ask how exactly you posted the above message? > > Your message has no threading headers (In-Reply-To or References), but I > _think_ I never received the message to which you appear to be reacting > (that one by "Jonathan"). I cannot prove it beyond doubt because of the > missing headers. Was "Jonathan"'s message posted on the haskell-cafe > mailing list at all? Or what else is going on here? > > Ian, who cares about his mailing lists > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > Do obvious transformation on domain to reply privately _only_ on Usenet. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

2 1

Network Connect Timeouts
by Mark Fine 14 Oct '17

14 Oct '17

I'd like a configurable network connect timeout. Has anyone solved this reasonably? *System.Timeout.timeout* times out connections, but works on the granularity of the life of the connection. Is there a reasonable way to configure a timeout around just establishing the connection? Maybe something like a conditional timeout that enables an action to disable the timeout once it expires? As a workaround, I'm spinning trying to successfully connect first before trying to connect for real: -- | Try the TCP connection and see if you can connect... -- tryTCPClient :: Int -> ClientSettings -> IO () tryTCPClient microseconds settings = do ok <- newIORef False void $ timeout microseconds $ runTCPClient settings $ const $ writeIORef ok True ok' <- readIORef ok unless ok' $ tryTCPClient microseconds settings -- | Wrap runTCPClient with a connect timeout. -- -- Tries the TCP connection first, and the runs the regular runTCPClient. -- Of course, this only enforces a TCP connect timeout on the first connect. -- The second TCP connect has no timeout :( -- runTCPClient' :: Int -> ClientSettings -> (AppData -> IO a) -> IO a runTCPClient' microseconds settings action = do tryTCPClient microseconds settings runTCPClient settings action I've also tried running the *tryTCPClient* in its own thread concurrently with *runTCPClient* and throwing an exception if it can't connect in *microseconds*. None of these offer an actual true connection establishment timeout. Has anyone found a way to solve this? Thanks! Mark

3 2

Pattern Matching with Different Types
by Yotam Ohad 11 Oct '17

11 Oct '17

Hello cafe, I am trying to do the following: data Foo = Foo { a1 :: Int -> Int, a2 :: Int -> Char } data Bar = Bar { a1 :: Int -> Int } func :: a -> Maybe (Int -> Int) -- a is either Foo or Bar func (x::(Bar/Foo) = Just $ a1 x func _ = Nothing I'm not sure how to implement this. All I know that the types are matching so I think it could be possible. Thanks for your help -Yotam

4 3

Galois is hiring
by Eric Mertens 11 Oct '17

11 Oct '17

Hello, Galois is growing again! We're looking for researchers, principal investigators, software engineers, including those with expertise in functional programming, formal methods, machine learning, embedded systems, computer security, or networking. For the exact available positions, please have a look at our website: http://galois.com/careers We now have three locations: Portland, Ore.; Arlington, Va.; and Dayton, Ohio. There are positions available at all locations. We are looking for people to work on-site, not remotely. Mostly, we are looking for candidates who are already authorized to work in the US, but in exceptional situations we can work with the candidate to obtain the necessary documentation. If you are interested, please apply through the web site. If you have questions about working at Galois, you're welcome to contact me directly. Best regards, Eric Mertens glguy

1 0

random library
by Kazu Yamamoto 11 Oct '17

11 Oct '17

Hello, I'm preparing for a major release of the dns package version 3.0.0. https://github.com/kazu-yamamoto/dns/issues/88 Before the release, I would like to replace the random package since it is slow. I'm looking for a random library which is - fast - thread-safe (good for concurrent use) Any recommendations? // Kazu

6 9

Re: [Haskell-cafe] random library
by dominic＠steinitz.org 11 Oct '17

11 Oct '17

No-one should be using the de facto random package. It is slow and produces surprising results. I think one of the posters suggested using mwc-random and splitting by using a different seed. Although mwc-random has reasonably good properties, there is no guarantee about how correlated the various streams of random numbers will be. QuickCheck uses tf-random to avoid such problems. There is also a version of SplitMix https://hackage.haskell.org/package/splitmix <https://hackage.haskell.org/package/splitmix> but I don’t think this has been heavily road-tested. But in this case, cryptographically secure randomness is required so I would follow Thomas’ suggestion. PS I just noticed my spellchecker changed defacto to defect! Perhaps AI is taking over. > All, > > Interesting library! Here's a link: http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html <http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html> > > Thomas, > > In the linked docs, there's a claim that Hash DRBG is the fastest cryptographically secure RNG on Hackage. Do you have a link to the benchmark results, or perhaps some updated ones? Unlike Viktor, I'm interested in less secure applications, but if the performance is good, it might be worth switching from the defacto random package. > > Thanks, > Jonathan > > On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson <thomas.dubuisson(a)gmail.com <mailto:thomas.dubuisson@gmail.com>> wrote: >> The hash drbg from the drbg package should meet your needs. >> Deterministic, >> pure Haskell except the actual hash function. >> >> On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" <ietf-dane(a)dukhovni.org <mailto:ietf-dane@dukhovni.org>> >> wrote: >> >>> >>>> On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) <kazu(a)iij.ad.jp <mailto:kazu@iij.ad.jp>> >>> wrote: >>>> >>>> Before the release, I would like to replace the random package >> since >>>> it is slow. I'm looking for a random library which is >>>> - fast >>>> - thread-safe (good for concurrent use) >>>> >>>> Any recommendations? >>> >>> Just to make it more interesting, I should mention that the RNG >>> should be not just statistically random, but should in fact be >>> crypto random (resist predictability through cryptanalysis when >>> properly seeded). >>> >>> So indeed there are two more issues here: >>> >>> - Securely seeding the RNG (likely using the OS API for >>> random seeds, and/or the RDSEED/RDRAND instructions on >>> Intel CPUs), IIRC we can that from cryptonite, I hope >>> at a reasonable cost. >>> >>> - Choosing a suitable DRBG based on the seed. Likely again >>> something from cryptonite. >>> >>> Some time back I posted to the cryptography list about the >>> soundness of relying on RDRAND in cryptonite's RNG (uses >>> it instead of /dev/urandom and the like when available). >>> The rough consensus IIRC was not rely solely on RDRAND. >>> I never went back to write a PR to address that... >>> >>> http://www.metzdowd.com/pipermail/cryptography/2016- <http://www.metzdowd.com/pipermail/cryptography/2016-> >>> November/thread.html#30859 >>> >>> -- >>> Viktor. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

parallel strategies for foldMap?
by waldmann 10 Oct '17

10 Oct '17

Dear Cafe, I wonder if there is some accepted wisdom (and implementation) to support parallel foldMap in some uniform way. It should probably be tuneable for the case that mappend is less or more expensive than the function to apply in the elements. I can do the following, but it does not parallelize the mappends: import qualified Data.Foldable as F import Control.Parallel.Strategies foldMapPar :: (Foldable f, Monoid b) => Int -> (a -> b) -> f a -> b foldMapPar block f xs = F.fold ( map f (F.toList xs) `using` parBuffer block rseq ) In my application, the Foldable thingy is an unbalanced tree. - J.W. ( the above is a genuine question, while the following is a genuine announcement: don't miss the early registration deadline for "Haskell in Leipzig" https://hal2017.softbase.org/ )

1 0

Confusing `bind` and (>>=)
by mirone 10 Oct '17

10 Oct '17

Hi there, I'm learning haskell for weeks and I'm trying to write a parser using haskell. First I create a datatype: newtype Parser a = P (String -> [(a, String)]) I create a function called `bind` : bind :: Parser a -> ( a -> Parser b) -> Parser b bind f g = P $ \s -> concatMap (\(a, s') -> parse (g a) s') $ parse f s and then: instance Monad Parser where (>>=) = bind that's looks cool, than I write a function liftToken :: (Char -> [a]) -> Parser a liftToken f = P g where g [] = [] g (c:cs) = f c >>= (\x -> return (x, cs)) It works well, then I change this function to liftToken :: (Char -> [a]) -> Parser a liftToken f = P g where g [] = [] g (c:cs) = f c `bind` (\x -> return (x, cs)) GHC throw errors: regular.hs|153 col 14 error| • Couldn't match expected type ‘Parser t0’ with actual type ‘[a]’ • In the first argument of ‘bind’, namely ‘f c’ In the expression: f c `bind` (\ x -> return (x, cs)) In an equation for ‘g’: g (c : cs) = f c `bind` (\ x -> return (x, cs)) • Relevant bindings include f :: Char -> [a] (bound at regular.hs:151:11) liftToken :: (Char -> [a]) -> Parser a (bound at regular.hs:151:1) That's really confusing, why I can use (>>=) but I can't use `bind`? Is there any difference between them?

3 2

Let's plan BayHac 2018
by Dan Burton 09 Oct '17

09 Oct '17

I'm thinking late February this time. How is that looking for everyone? I am also hoping to cut down a touch on the talks and focus a little more on the hacking. Maybe bring back the old koans, or write some new ones. Location has not yet been decided. Obviously it will be somewhere in the San Francisco Bay Area or Silicon Valley. Over the next month or so I will be reviewing the data from the last survey and reaching out to those who expressed interest in organizing the event. Regardless of whether you filled out the survey or not, please feel free to contact me if you are interested in assisting with the planning and organizing of BayHac 2018.

2 1