- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Explicit approach to lazy effects For probability monad?
by Olaf Klinke 14 Nov '19

14 Nov '19

Hi Benjamin, Your example code seems to deal with two distinct types: The do-notation is about the effects monad (on the random number generator?) and the `sample` function pulls whatever representation you have for an actual probability distribution into this effect monad. In my mental model, the argument to `sample` represents a function Double -> x that interprets a number coming out of the standard random number generator as an element of type x. I suggest to consider the following two properties of the mathematical probability monad (a.k.a. the Giry monad), which I will use as syntactic re-write rules in your modeling language. The first property is Fubini's Theorem. In Haskell terms it says that for all f, a :: m x and b :: m y the two terms do {x <- a; y <- b; f x y} do {y <- b; x <- a; f x y} are semantically equivalent. (For state monads, this fails.) Monads where this holds are said to be commutative. If you have two urns, then drawing from the left and then drawing from the right is the same as first drawing from the right and then drawing from the left. Using Fubini, we can swap the first two lines in your example: model = do cond <- bernoulli 0.5 x <- normal 0 1 return (if cond == 1 then x else 0) This desugars to bernoulli 0.5 >>= (\cond -> normal 0 1 >>= (\x -> return (if cond == 1 then x else return 0))) bernoulli 0.5 >>= (\cond -> fmap (\x -> if cond == 1 then x else 0) (normal 0 1)) The second property is a kind of lazyness, namely fmap (const x) and return are semantically equivalent. which holds for mathematical distributions (but not for state monads). Now one could argue that in case cond == 0 the innermost function is constant in x, in which case the whole thing does not depend on the argument (normal 0 1). The Lemma we need here is semantic equivalence of the following two lambda terms. \cond -> \x -> if cond == 1 then x else 0 \cond -> if cond == 1 then id else const 0 If the above is admissible then the following syntactic transformation is allowed: model = do cond <- bernoulli 0.5 if cond == 1 then normal 0 1 else return 0 which makes it obvious that the normal distribution is only sampled when needed. But I don't know whether you would regard this as the same model. Notice that I disregarded your `sample` function. That is, my monadic language is the monad of probabilites, not the monad of state transformations of a random number generator. Maybe you can delay using the random number generator until the very end? I don't know the complete set of operations your modeling language sports. If that delay is possible, then maybe you can use a monad that has the above two properties (e.g. a reader monad) and only feed the random numbers to the final model. As proof of concept, consider the following. type Model = Reader Double model :: Model Int model = do x <- reader (\r -> last [1..round (recip r)]) cond <- reader (\r -> r > 0.5) return (if cond then x else 0) runReader model is fast for very small inputs, which would not be the case when the first line was always evaluated. Cheers, Olaf

3 5

Statically checked overloaded strings
by Christopher Done 14 Nov '19

14 Nov '19

Hi all, I just came up with this neat trick for adding static checks to overloaded strings: https://gist.github.com/chrisdone/809296b769ee36d352ae4f8dbe89a364 Hope it's helpful. I wonder whether the GHC devs would be open to a small patch to permit: $$"..." :-) Cheers, Chris

2 1

[ANNOUNCE] GHC 8.8.1 is now available
by Ben Gamari 14 Nov '19

14 Nov '19

Hello everyone, The GHC team is pleased to announce the release candidate for GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/ghc/8.8.1 This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Visible kind applications are now supported (GHC Proposal #15) * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator significantly improving the runtime performance of some kernels * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * Users can write `forall` in more contexts (GHC Proposal #7) * The pattern-match checker is now more precise in the presence of strict fields with uninhabited types. * A comprehensive audit of GHC's memory ordering barriers has been performed, resulting in a number of fixes that should significantly improve the reliability of programs on architectures with weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 implementations). * A long-standing linker limitation rendering GHCi unusable with projects with cyclic symbol dependencies has been fixed (#13786) * Further work on the Hadrian build system * Countless miscellaneous bug-fixes Unfortunately, due to a build issue (#17108) found late in the release process i386 Windows builds are currently unavailable. These will be provided in the coming weeks. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.h…

8 14

Second call for draft papers for TFPIE 2020 (Trends in Functional Programming in Education)
by Jurriaan Hage 14 Nov '19

14 Nov '19

Hello, Please, find below the second call for draft papers for TFPIE 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Chair of TFPIE 2020 ======================================================================== TFPIE 2020 Call for papers http://www.staff.science.uu.nl/~hage0101/tfpie2020/index.html February 12th 2020, Krakow, Poland (co-located with TFP 2020 and Lambda Days) TFPIE 2020 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP and Computational Thinking FP and Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy The pedagogy of teaching FP FP and e-learning: MOOCs, automated assessment etc. Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. On top of the lecture itself, the presentation can also provide commentary on the lecture. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 20 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2020 . After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles that will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Dates Submission deadline: January 14th 2020, Anywhere on Earth. Notification: January 17th 2020 TFPIE Registration Deadline: January 20th 2020 Workshop: February 12th 2020 Submission for formal review: April 19th 2020, Anywhere on Earth. Notification of full article: June 6th 2020 Camera ready: July 1st 2020 Program Committee Olaf Chitil - University of Kent Youyou Cong - Tokyo Institute of Technology Marko van Eekelen - Open University of the Netherlands and Radboud University Nijmegen Jurriaan Hage (Chair) - Utrecht University Marco T. Morazan - Seton Hall University, USA Sharon Tuttle - Humboldt State University, USA Janis Voigtlaender - University of Duisburg-Essen Viktoria Zsok - Eotvos Lorand University Note: information on TFP is available at http://www.cse.chalmers.se/~rjmh/tfp/

1 0

Code coverage: mark certain function calls as covered
by Özgür Akgün 13 Nov '19

13 Nov '19

This may sound like a bizarre request, but I feel I can't be the only one. I have a function called "bug". This is essentially a special case of "error", but I am disciplined and I only use this function to mark parts of my code I believe are unreachable. So something like: data Term = X ... | Y ... | Z ... -- the argument can only be X or Y in this part of the program f :: Term -> ... f (X ...) = ... f (Y ...) = ... f Z{} = bug "This should never happen (in f)" You might hate this style of programming, and frankly I am not a fan either. But sometimes we have to write partial functions and I am at least trying to mark the cases explicitly in these cases. So this is my question: if I did a good job and if the Z case above is indeed unreachable, the code coverage report will always flag it as uncovered and in the overall report this will make it harder for me to see the parts of my code which aren't covered and should be. I'd like a way of marking (= generating a tick for?) every call to this function bug as covered. Please let me know if there is a better place to ask this question. I checked and hpc <http://hackage.haskell.org/package/hpc>'s issue tracker is shared with GHC's and I wasn't sure if they'd appreciate a question there. -- Özgür Akgün

2 1

First release of sexpresso
by Vincent Archambault-Bouffard 11 Nov '19

11 Nov '19

Hello, I'm pleased to announce the first release of the sexpresso [0] library on Hackage. sexpresso is a library to parse, print and work with S-expression. You can for example : - Customize the opening and closing tag, usually '(' and ')'. - Specify if space is needed between atoms (or between only a subset of atoms) - The datatype for S-expression (SExpr) has a extra parameter to make parsing, working and printing with multiple "type" of S-expression, like Scheme list (...) and Scheme vector #(....), easier - Do much more ... read the doc on Hackage or the README on github [1] ! I plan to improve the printer and add recursive scheme soon. [0] http://hackage.haskell.org/package/sexpresso [1] https://github.com/archambaultv/sexpresso Vincent Archambault

2 1

Help wanted: Postfix admin guru for Haskell.org
by Gershom B 10 Nov '19

10 Nov '19

We've been getting increasing amounts of bounces and dropped mail for haskell.org emails (things sent hackage trustees, things sent from our wiki and hackage servers, etc). We _mainly_ have kept things working, but it looks like policies have been amped up in terms of requiring various measures. Additionally, there's something about reverse dns and valid hostnames that seems to not be configured correctly, according to mxtoolbox. Along with all that, we'd really like to migrate the mail infrastructure to our new packet servers, away from rackspace. As such, we could use some concentrated help from someone familiar with maintaining and administering postfix servers, if someone is up to volunteer for the task. Thanks! --Gershom

2 1

Type class constraints in rewrite rules
by Janus Troelsen 09 Nov '19

09 Nov '19

Hi, I am trying to speed up some code using the Simplicity library by roconnor. He suggested I apply a rewrite rule to implement the full-adder using Haskell's addition: > fullAdder @(Kleisli m) w > into > Kleisli (\((a,b),c) -> return $ let sum = fromWord w a + fromWord w b + fromWord1 c in (toBit (sum >= 2 ^ wordSize w), toWord w sum)) I turned that description into a rewrite rule by prepending "forall m w.". But that results in "Forall'd variable ‘m’ does not appear on left hand side" and "Not in scope: type variable ‘m’" (which seems contradictory?) So I thought, OK, typically Type Applications are not necessary, I will just remove it. So the RULE becomes: "fullAdderOpt" forall w. fullAdder w = Kleisli (\((a,b),c) -> return $ let sum = fromWord w a + fromWord w b + fromWord1 c in (toBit (sum >= 2 ^ wordSize w), toWord w sum)) but compiling that, I get: > Could not deduce (Monad m) arising from a use of ‘return’". > Possible fix: add (Monad m) to the context of the RULE "fullAdderOpt" OK, that must mean I should prepend "(Monad m) =>". I tried inserting that either before or after the forall, but both variants are parse errors. So I am suspecting a GHC bug, since I was suggested to do something that doesn't parse. But really, I am just wondering how to make a rewrite rule that does what roconnor suggested. The full source code of the final version is here: https://hushfile.it/api/file?fileid=5dc706576e329 Regards, Janus

1 0

ANN: ban-instance-0.1.0.1
by Jack Kelly 08 Nov '19

08 Nov '19

I have just pushed an initial release of ban-instance[1] to Hackage. ban-instance uses template haskell to generate compile errors for typeclass instances that should not exist: -- Declare that Foo should never have a ToJSON instance $(banInstance [t|ToJSON Foo|] "why ToJSON Foo should never be defined") The custom errors then say why an instance is banned: • Attempt to use banned instance (ToJSON Foo) Reason for banning: why ToJSON Foo should never be defined Instance banned at [moduleName] filePath:lineNumber We have found this useful to prevent definition of ToJSON/FromJSON instances on core data types, as this forces programmers to instead place the serialisation instances on newtypes at the serialisation boundary. GitHub issues and PRs are welcome[2]. In particular, there are currently a few limitations: 1. There is currently no support for classes with associated types or associated data types; 2. It would be great to generate haddocks for banned instances, marking them as such; and 3. Type quotations [t|...|] do not support free variables (GHC#5616). Nevertheless, I hope that it is useful. Best, -- Jack [1]: http://hackage.haskell.org/package/ban-instance-0.1.0.1 [2]: https://github.com/qfpl/ban-instance/

1 0

[ANN] Keycloak-hs
by Corentin Dupont 07 Nov '19

07 Nov '19

Hello, I'm very proud to announce the release of Keycloak-hs, a library to access Keycloak: http://hackage.haskell.org/package/keycloak-hs. Keycloak (www.keycloak.org) is a tool allowing to authenticate users and protect your API resources. I included a tutorial in the README file. Keycloak as many many features, so this library will evolve to cover more. Help/PRs are welcome! Cheers! Corentin

1 0