- Haskell-Cafe - Haskell.org

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 11 Oct '17

11 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

Kyiv Haskell Learning Group Meetups
by Kostiantyn Rybnikov 09 Oct '17

09 Oct '17

Hi! We're starting a Haskell Learning Group in Kyiv, Ukraine. First Meetup will be at 17 October (Tuesday) and will continue on weekly basis at the Institute of Mathematics. See full info about the first meetup at https://www.meetup.com/Kyiv-Haskell-Learning-Group/events/243945548/ Info about the course itself (in Ukrainian): https://github.com/KyivHaskell/haskell-study-startup See you there!

2 2

ANN: hmep -- genetic multi expression programming package
by masterdeZign 09 Oct '17

09 Oct '17

Dear Haskell community, I am delighted to contribute a new package for the first time. Today, I am happy to announce `hmep` http://hackage.haskell.org/package/hmep/ bringing Multi Expression Programming to Haskell. Multi Expression Programming is a genetic programming variant encoding multiple solutions in the same chromosome. A chromosome is a computer program. Each gene is featuring code reuse. The latest version is of course on GitHub https://github.com/masterdezign/hmep Thank you for your kind attention, Happy Monday, Bogdan Penkovsky

1 0

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 09 Oct '17

09 Oct '17

Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, deadline 31st October 2017. Please share! Best wishes, Graham ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st October 2017 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 31st October 2017. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Deprecating STM invariant mechanism
by Ben Gamari 09 Oct '17

09 Oct '17

tl;dr. Do you use Control.Monad.STM.always? If so say so on this [1] proposal otherwise the interface may be removed. Hello everyone, GHC's STM subsystem has long had the ability to run user-specified invariant checks when committing transactions, embodied by the Control.Monad.STM.always and alwaysSucceeds functions. However, if Hackage is any indication this feature has seen very little use of the past ten years. In fact, it has very likely been quite broken (#14310) for this entire duration. Consequently, I suggest that we begin deprecating the mechanism. See the deprecation Proposal [1] for full details. Please leave a comment if you object. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/77

2 1

CoqPL 2018: Call for Presentations
by Sergey, Ilya 07 Oct '17

07 Oct '17

==================================================================== CoqPL 2018 Coq for Programming Languages -- A Coq users and developers meeting 13 January 2018, co-located with POPL (as usual) Los Angeles, California, United States CALL FOR PRESENTATIONS https://popl18.sigplan.org/track/CoqPL-2018 ==================================================================== Workshop Overview ----------------- The series of CoqPL workshops provide an opportunity for programming languages researchers to meet and interact with one another and members from the core Coq development team. At the meeting, we will discuss upcoming new features, see talks and demonstrations of exciting current projects, solicit feedback for potential future changes, and generally work to strengthen the vibrant community around our favourite proof assistant. Topics in scope include but are no limited to: * General purpose libraries and tactic language extensions; * Domain-specific libraries for programming language formalization and verification; * IDEs, profilers, tracers, debuggers, and testing tools; * Reports on ongoing proof efforts conducted via (or in the context of) the Coq proof assistant; * Experience reports from Coq usage in educational or industrial contexts. To foster open discussion of cutting edge research which can later be published in full conference proceedings, we will not publish papers from the workshop. Workshop Format --------------- The workshop format will be driven by members of the Coq community. We will solicit abstracts for talks and proposals for demonstrations and flesh out format details based on responses. We expect the final program to include experiment reports, panel discussions, and invited talks. Talks will be selected according to relevance to the workshop, based on the submission of an extended abstract. Submission Details ------------------ * Abstract Submission : Monday, October, 16th, 2017 * Author Notification : Monday, November 6th, 2017 * Workshop : Saturday, January 13th, 2018 Submissions should be extended abstracts of 1-2 pages in portable document format (PDF). Submission is via EasyChair: https://easychair.org/conferences/?conf=coqpl2018 Program Committee ----------------- * Yves Bertot, INRIA (Workshop Co-chair) * Ilya Sergey, University College London (Workshop Co-chair) * Andrew Appel, Princeton University * Benjamin Delaware, Purdue University * Xinyu Feng, University of Science and Technology of China * Hugo Herbelin, INRIA * Chantal Keller, Université Paris-Sud * Ekaterina Komendantskaya, Heriot-Watt University * Beta Ziliani, Universidad Nacional de Córdoba Contact ----------------- For any queries, please contact : coqpl2018 at easychair.org<http://easychair.org>

1 0

claiming maintainer position of a HackageDB package
by Guillaume Hoffmann 06 Oct '17

06 Oct '17

Hi, I would like to submit a new version of the following package: https://hackage.haskell.org/package/mime-string Unfortunately, I only received private consent from the current maintainer that I would become the maintainer of this package, more than one month ago. Since then I had not received any answer to my request and I cannot upload a new version to HackageDB. Is there a procedure I could summon to become the maintainer of this package on HackageDB? Thanks Guillaume PS: for the anecdote, darcsden needs this new version of mime-string.

2 2