- Haskell-Cafe - Haskell.org

monoid fold concurrently
by PICCA Frederic-Emmanuel 16 Nov '19

16 Nov '19

Hello, I would like to create a fucntion whcih does mkCube :: [IO a] -> IO a mkCube = ... I want to fold all this concurrently in order to obtain the final a I have a function like this merge :: a -> a -> IO a in order to sort of merge two a into another one. I did not found something like this on hoogle. so I would like your advices in order to write mkCube Thanks Frederic

2 7

FLOPS 2020: DEADLINE EXTENSION (abstract 22 Nov, full paper 29 Nov)
by Shin-Cheng Mu 16 Nov '19

16 Nov '19

FINAL Call For Papers (*** DEADLINE EXTENSION ***) FLOPS 2020: 15th International Symposium on Functional and Logic Programming In-Cooperation with ACM SIGPLAN =============================== 23-25 April, 2020, Akita, Japan https://www.ipl.riec.tohoku.ac.jp/FLOPS2020/ Writing down detailed computational steps is not the only way of programming. An alternative, being used increasingly in practice, is to start by writing down the desired properties of the result. The computational steps are then (semi-)automatically derived from these higher-level specifications. Examples of this declarative style of programming include functional and logic programming, program transformation and rewriting, and extracting programs from proofs of their correctness. FLOPS aims to bring together practitioners, researchers and implementors of the declarative programming paradigm, to discuss mutually interesting results and common problems: theoretical advances, their implementations in language systems and tools, and applications of these systems in practice. The scope includes all aspects of the design, semantics, theory, applications, implementations, and teaching of declarative programming. FLOPS specifically aims to promote cross-fertilization between theory and practice and among different styles of declarative programming. *** Scope *** FLOPS solicits original papers in all areas of the declarative programming: * functional, logic, functional-logic programming, rewriting systems, formal methods and model checking, program transformations and program refinements, developing programs with the help of theorem provers or SAT/SMT solvers, verifying properties of programs using declarative programming techniques; * foundations, language design, implementation issues (compilation techniques, memory management, run-time systems, etc.), applications and case studies. FLOPS promotes cross-fertilization among different styles of declarative programming. Therefore, research papers must be written to be understandable by the wide audience of declarative programmers and researchers. In particular, each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant for its area, and comparing it with previous work. Submission of system descriptions and declarative pearls are especially encouraged. *** Submission *** Submissions should fall into one of the following categories: * Regular research papers: they should describe new results and will be judged on originality, correctness, and significance. * System descriptions: they should describe a working system and will be judged on originality, usefulness, and design. * Declarative pearls: new and excellent declarative programs or theories with illustrative applications. System descriptions and declarative pearls must be explicitly marked as such in the title. Submissions must be unpublished and not submitted for publication elsewhere. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. See also ACM SIGPLAN Republication Policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication. Submissions must be written in English and can be up to 15 pages excluding references, though system descriptions and pearls are typically shorter. The formatting has to conform to Springer's guidelines. Regular research papers should be supported by proofs and/or experimental results. In case of lack of space, this supporting information should be made accessible otherwise (e.g., a link to an anonymized Web page or an appendix, which does not count towards the page limit). However, it is the responsibility of the authors to guarantee that their paper can be understood and appreciated without referring to this supporting information; reviewers may simply choose not to look at it when writing their review. FLOPS 2020 will employ a double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. author names and institutions must be omitted, and 2. references to authors' own related work should be in the third person (e.g., not "We build on our previous work..." but rather "We build on the work of..."). The purpose of this process is to help the reviewers come to a judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. Papers should be submitted electronically at https://easychair.org/conferences/?conf=flops2020 Springer Guidelines https://www.springer.com/gp/computer-science/lncs/conference-proceedings-gu… *** Proceedings *** The proceedings will be published by Springer International Publishing in the Lecture Notes in Computer Science (LNCS) series (www.springer.com/lncs) *** Important Dates *** [EXTENDED] 22 November 2019 (AoE): Abstract submission [EXTENDED] 29 November 2019 (AoE): Submission deadline [EXTENDED] 31 January 2020: Author notification [EXTENDED] 20 February 2020: Camera ready due 23-25 April 2020: FLOPS Symposium *** Programming Comittee *** Elvira Albert Universidad Complutense de Madrid María Alpuente Universitat Politècnica de València Edwin Brady University of St Andrews Michael Hanus CAU Kiel Nao Hirokawa JAIST Zhenjiang Hu Peking University John Hughes Chalmers University of Technology Kazuhiro Inaba Google Shin-Ya Katsumata National Institute of Informatics Ekaterina Komendantskaya Heriot-Watt University Leonidas Lampropoulos University of Pennsylvania Akimasa Morihata The University of Tokyo Shin-Cheng Mu Academia Sinica Keisuke Nakano Tohoku University (co-chair) Koji Nakazawa Nagoya University Enrico Pontelli New Mexico State University Didier Remy INRIA Ricardo Rocha University of Porto Konstantinos Sagonas Uppsala University (co-chair) Ilya Sergey Yale-NUS College Kohei Suenaga Kyoto University Tachio Terauchi Waseda University Kazushige Terui Kyoto University Simon Thompson University of Kent Philip Wadler, University of Edinburgh *** Organizers *** Keisuke Nakano Tohoku University, Japan (PC Co-Chair, General Chair) Kostis Sagonas Uppsala University, Sweden (PC Co-Chair) Kazuyuki Asada Tohoku University, Japan (Local Co-Chair) Ryoma Sin'ya Akita University, Japan (Local Co-Chair) Katsuhiro Ueno Tohoku University, Japan (Local Co-Chair) *** Contact Address *** flops2020 _AT_ easychair.org

1 0

GHC API: parsing as much as I can
by Artem Pelenitsyn 16 Nov '19

16 Nov '19

Hello Cafe, I need an advice on how to use GHC API to parse big collections of Haskell source files. Say, I want to collect ASTs of everything that is on Hackage. I downloaded the whole Hackage (latest versions only) and have it locally now. I tried simple advice found in the Parse module documentation: https://hackage.haskell.org/package/ghc-8.6.5/docs/Parser.html runParser :: DynFlags -> String -> P a -> ParseResult a runParser flags str parser = unP parser parseState where filename = "<interactive>" location = mkRealSrcLoc (mkFastString filename) 1 1 buffer = stringToStringBuffer str parseState = mkPState flags buffer location It mostly works: 75% of .hs files on Hackage seem to parse fine. I looked into the rest 25% and noticed that this snippet can't handle files using GHC extensions such as RankNTypes, TemplateHaskell, BangPatterns, etc.when given the default DynFlags. This leads me to the question of how should I initialize DynFlags? Currently, I use this for getting DynFlags: initDflags :: IO DynFlags initDflags = do let ldir = Just libdir mySettings <- initSysTools ldir myLlvmConfig <- initLlvmConfig ldir initDynFlags (defaultDynFlags mySettings myLlvmConfig) I understand that simple parsing of individual files can't take into account extensions activated inside .cabal files. But I'd expect that it should be possible to, at least, consider the extensions mentioned in the LANGUAGE pragmas. Currently, this isn't happening. Any suggestions on how to achieve this are welcomed. I probably won't get to parsing 100% of Hackage, but I'd hope for better than the current 75%. -- Best wishes, Artem

2 2

ANN: semialign-extras-0.1.0.0, and a request for help
by Jack Kelly 15 Nov '19

15 Nov '19

I have just pushed an initial release of semialign-extras[1] to Hackage. semialign-extras aims to collect interesting abstractions/operations that: 1. Build on top of (at least) the Semialign typeclass, or related classes from the semialign universe; and 2. Do not belong inside other packages in the semialign universe. PRs that serve these goals are most welcome, as are GitHub issues[2]. Currently, there are two modules: * Data.Semialign.Diff has diffing/patching for Semialigns; and * Data.Semialign.Merge has a collection of merge operations for Semialigns which are also Filterable/Traversable/Witherable Request for help: The functions in Data.Semialign.Diff work across a lot of types, but are are often not the most efficient way to diff. There is a high-performance merge API for Data.Map.Map in Data.Map.Merge.Lazy[3], and it would be great to have some rewrite rules that took advantage of this. I have been able to write rules that GHC accepts, but not make them actually fire[4]. I'd be grateful for any assistance people can provide. Best, -- Jack [1]: http://hackage.haskell.org/package/semialign-extras-0.1.0.0 [2]: https://github.com/qfpl/semialign-extras [3]: https://hackage.haskell.org/package/containers-0.6.0.1/docs/Data-Map-Merge-… [4]: https://github.com/qfpl/semialign-extras/issues/3

1 0

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

15 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 14 Nov '19

14 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 12 Nov '19

12 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