- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Haskell Symposium: early reg deadline is next week
by Johannes Waldmann 17 Jul '19

17 Jul '19

https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview list of accepted papers is invisible, navigation not usable, unless you allow third-party trackers (ajax.googleapis.com) - J.W.

4 4

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 11
by Information The FLOSS 16 Jul '19

16 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

ANN: New York Haskell CoHack, August 3
by Chris Smith 15 Jul '19

15 Jul '19

If you're not in New York, feel free to stop reading. Any Haskellers in the New York area, you're invited to the monthly CoHack on August 3rd, at the Microsoft Reactor space near Times Square. This is an informal collaboration between Haskellers working on a variety of projects. There's usually a good mix of everything from new Haskell programmers to seasoned veterans We'll have food and internet and hopefully collaborators, whether it's a long-standing project or a one-off weekend hack. Details at https://www.meetup.com/NY-Haskell/events/261277328/ I hope to see you there. There will also be lightning talks at the event, if you have anything you'd like to share. Signups will be same-day, and lightning talks are 10 minutes long, including setup and questions. Thanks, Chris

1 0

ANN: stack-2.1.3
by Emanuel Borsboom 14 Jul '19

14 Jul '19

See https://haskellstack.org/ for installation and upgrade instructions. **Changes since v2.1.1** Behavior changes: * Disable WAL mode for SQLite3 databases, to improve compatibility with some platforms and filesystems. See [#4876](https://github.com/commercialhaskell/stack/issues/4876). * By default, do not perform expiry checks in Hackage Security. See [#4928](https://github.com/commercialhaskell/stack/issues/4928). Other enhancements: * Do not rerun expected test failures. This is mostly a change that will only affect the Stackage Curator use case, but there is now an additional message letting the user know when a previously-failed test case is being rerun. * Move configure information for local packages back to .stack-work to improve caching. See [#4893](https://github.com/commercialhaskell/stack/issues/4893). Bug fixes: * Fix to allow dependencies on specific versions of local git repositories. See [#4862](https://github.com/commercialhaskell/stack/pull/4862) * Allow Stack commands to be run in Nix mode without having a project file available. See [#4854](https://github.com/commercialhaskell/stack/issues/4864). * Removes dependency on gnu-tar for OSX and Linux environment. The `--force-local` option was required only for windows environment. * Properly wait for the `tar` subprocess to complete before returning, thereby avoiding a SIGTERM screwing up GHC installation. See [#4888](https://github.com/commercialhaskell/stack/issues/4888). * Use package complete locations from lock files when resolving dependencies in `extra-deps`. See [#4887](https://github.com/commercialhaskell/stack/issues/4887). * Set the `HASKELL_DIST_DIR` environment to a proper package dist directory so `doctest` is able to load modules autogenerated by Cabal. * Expose package library when running tests. * Fix support for non-ASCII module names. See [4938](https://github.com/commercialhaskell/stack/issues/4938) Other changes: * Rename `pantry-tmp` package back to `pantry`, now that we have gained maintainership (which had been used by someone else for a candidate-only test that made it look like the name was free but prevented uploading a real package). **Thanks to all our contributors for this release:** * Alan Malloy * Alexander * Emanuel Borsboom * Kirill Zaborsky * Matt Audesse * Michael Snoyman * Mihai Maruseac * Sibi Prabakaran

1 0

Workshop in OCL and Textual Modeling (OCL 2019) - Deadline Extension
by Achim D. Brucker 14 Jul '19

14 Jul '19

CALL FOR PAPERS 19th International Workshop on OCL and Textual Modeling Co-located with MODELS 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and System, September 15-20, 2019, Munich, Germany http://oclworkshop.github.io ******************************************************************* **** Deadline Extension: One week (21st of July, 2019 - AoE) **** **** left to submit your papers! **** ******************************************************************* The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages (e.g., OCL, textual MOF, Epsilon, or Alloy) can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Submissions Four types of submissions will be considered: * Presentation only submission (not included in the workshop proceedings), e.g., for already published work. Authors should submit a short (1 page) abstract of their presentation. * Short papers (between 5 and 7 pages) describing new ideas or position papers. * Tool papers (between 5 and 7 pages) describing tools supporting textual modeling tools * Full papers (between 10 and 14 pages). All submissions should follow the LNCS format guidelines and should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2019). Accepted papers will be published online in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: 21 Jul 2019, AoE (extended) - Notification: 25 Aug 2019, AoE - Pre-Workshop CRC: 9 Sep 2019, AoE - Post-Workshop CRC: 5 Oct 2019, AoE -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Re: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads
by Olaf Klinke 12 Jul '19

12 Jul '19

Dear Juan, Is the following problem of the class you are considering? Given a predicate p :: (Integer -> Integer) -> Bool enumerate all functions f :: Integer -> Integer for which p f == True. The search space (Integer -> Integer) can be rendered into a tree of infinite width and depth: On the first level, branch on the value of f(0), on the next level branch on the value of f(1) and so forth. If the above problem were tractable, then you'd have an enumeration of the real numbers. If the target is to find whether there is at least one such f, then you have proven compactness of Baire space. So there must be something about your problem that remained unclear to me. Care to explain? Regards, Olaf P.S.: Infinite branching trees could be modeled as data Tree a = Tree (Integer -> Maybe (a,Tree a)) Maybe this can help bringing your algorithms closer to the literature on computable functions and recursion theory.

2 1

Huffman Library Maintainership
by Callan McGill 12 Jul '19

12 Jul '19

The huffman library (http://hackage.haskell.org/package/huffman) is very useful, but unfortunately hasn't been maintained in several years and does not compile with new versions of the containers library. We are incorporating huffman encoding as part of the American Museum of Natural History's PCG project (https://github.com/amnh/pcg) We have a locally "repaired" version of the huffman library that we have used in a prototype and would like to share the updates with the Haskell community. Nine months ago I contacted Maxime Henrion, the listed maintainer of the huffman library, about a pull request to incorporate the changes or taking up maintainership responsibility, whatever they would prefer to update the library and share the huffman encoding library updates with the rest of the community. Unfortunately I didn't receive any response from them. Per the listed protocol for requesting maintainership of a hackage package if the current maintainer cannot be reached ( https://wiki.haskell.org/Taking_over_a_package#If_you_cannot_contact_the_au…) I'm letting the Haskell community know that I am quite interested in taking over maintainership of the huffman library. I intend to update the library to compile with new versions of GHC and updated versions of the containers package. ~Alex Washburn, (recursion-ninja)

1 0

Haskell Symposium: early reg deadline is next week
by Richard Eisenberg 12 Jul '19

12 Jul '19

The early registration deadline is **18 July**. That's next week! Accepted papers are at https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview We will have two keynotes: • Mary Sheeran, of Chalmers University, will present Gender Equality in Academia: Meeting the Challenge on Thursday, 22 August. • Lennart Augustsson and Satnam Singh, both of Google Research, will co-present Haskell Use and Abuse at Scale on Friday, 23 August. Come join! Symposium details are below. I hope to see you there! Richard ================================================================================ ACM SIGPLAN CALL FOR PARTICIPATION Haskell Symposium 2019 Berlin, Germany 22--23 August, 2019 https://icfp19.sigplan.org/home/haskellsymp-2019 ================================================================================ The ACM SIGPLAN Haskell Symposium 2019 will be co-located with the 2019 International Conference on Functional Programming (ICFP). The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results.

1 0

Fwd: CFP: 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19), Co-located with SPLASH 2019
by Artem Pelenitsyn 12 Jul '19

12 Jul '19

---------- Forwarded message --------- De: Guido Chari <charig(a)gmail.com> Date: vie., 12 jul. 2019 a las 12:22 Subject: CFP: 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19), Co-located with SPLASH 2019 To: <seworld(a)sigsoft.org> ======================================================================== Call for Papers 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19) Co-located with SPLASH 2019 October 20, 2019, Athens, Greece https://2019.splashcon.org/track/meta-2019 Follow us on twitter @MetaAtSPLASH ======================================================================== The Meta’19 workshop aims to bring together researchers working on metaprogramming and reflection, as well as users building applications, language extensions and/or software tools using them. The challenges which metaprogramming faces are manifold. They start with formal reasoning about reflective programs, continue with performance and tooling, and reach into the empirical field to understand how metaprogramming is used and how it affects software maintainability. While industry accepted metaprogramming on a wide scale with Ruby, Scala, JavaScript, R and others, there is still a long road ahead to bring the same level of convenience, tooling, and understanding as for direct programming styles. Contributions to the workshop are welcome on a wide range of topics related to the design, implementation, and application of metaprogramming techniques, as well as empirical studies and formal methods for such systems and languages. ### Topics of Interest The workshop is a venue for all approaches that embrace metaprogramming, from static to dynamic techniques: - reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs - optimization techniques - contract systems, or typing of reflective programs - reflection and metaobject protocols to enable tooling - case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools - empirical evaluation of metaprogramming solutions - security in reflective systems and capability-based designs - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) - surveys, conceptualization, taxonomization, and formalization of existing approaches ### Workshop Format and Submissions This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. Papers submitted by the first deadline will be considered for publication in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. For all papers, use of the SIGPLAN acmart style is mandatory: http://www.sigplan.org/Resources/Author/. Please use the provided double-column templates for Latex or Word. technical paper: max. 8 pages, excluding references position and work-in-progress paper: 1-4 pages, excluding references technology demos or a posters: 1-page abstract Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work, but will not be considered for publication in the ACM DL. For the submission, please use the submission system at: https://meta19.hotcrp.com/ ### Important Dates (TODO) 26 Jul 2019 - Abstract Submission 2 Aug 2019 - Paper Submission (considered for ACM DL) 23 Aug 2019 - Notification 28 Aug 2019 - Demo, position or work-in-progress paper submission 20 Sep 2019 - Demo, position or work-in-progress paper notification ### Steering Committee Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, University of Kent ### Organizing Committee Guido Chari, Czech Technical University Christophe Scholliers, Ghent University ### Program Committee Nada Amin, University of Cambridge, UK Edwin Brady, University of St Andrews, UK Andrei Chis, Feenk, Switzerland David Thrane Christiansen, Galois, Portland, Oregon, USA Tom Van Cutsem, Bell Labs, Belgium Ryan Culpepper, Czech Technical University, Prague, Czechia Jennifer Hacket, University of Nottingham, UK Robert Hirschfield, Hasso Plattner Institute, Germany James Noble, Victoria University Wellington, New Zealand Bruno C. d. S. Oliveira, The University of Hong Kong Cyrus Omar, University of Chicago, USA Guillermo Polito, Inria Lille, France Eric Tanter, Universidad de Chile, Chile ### Contact Information For further inquiries, do not hesitate to contact the organizers via meta-at-splash19 AT googlegroups.com http://2019.splashcon.org/track/meta-2019 -- You received this message because you are subscribed to the Google Groups "PRL-jv" group. To unsubscribe from this group and stop receiving emails from it, send an email to PRL-jv+unsubscribe(a)googlegroups.com. To post to this group, send email to PRL-jv(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/PRL-jv/CAO4Coc-WQ21XZQNPLCiXCE2ZTXoPYT4i7… <https://groups.google.com/d/msgid/PRL-jv/CAO4Coc-WQ21XZQNPLCiXCE2ZTXoPYT4i7…> . For more options, visit https://groups.google.com/d/optout.

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 7
by Information The FLOSS 12 Jul '19

12 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

"Quantization" of computations, or step-wise termination, as an extension of Logic Monads
by Juan Casanova 12 Jul '19

12 Jul '19

Dear all, I just subscribed to this list so I'm not familiar with the usual way to go about things here. I hope you'll excuse any cultural mistakes I might make. I'll also try to keep this message as short as possible, but this is hard for me and it is a complex topic, so I will presumably fail. Apologies for that in advance. Short introduction. I'm a PhD student at University of Edinburgh. My research is not on programming languages itself, but during the course of it I ended up programming in Haskell and more particularly faced a problem that I developed a strategy (and eventually a library) for. After some discussions with my supervisors and with some more Haskell experienced people around university, they suggested that I looked into some existing work and also that I posted on this list, and here I am. Let me introduce the problem that I'm trying to solve itself. I have a particular (yet somehow typical) case of non-determinism (search) in the program that I have been writing. It is characterized by: - No joining back of branches ever. - Potentially infinite depth (this is usual). - Potentially infinite width. Meaning that at a single point I may have an infinite amount of possible paths to follow. - It is critical that the search is complete. After reading a bit, I have realized this is usually referred to as being a fair search order. For me this means that there can be many (infinite) valid solutions in the search space, and I want to find all of them (i.e. for every valid solution, the program will eventually output it). As I said, I developed my own (particular) approach to this, then generalized it in a library, and then, after talking to some people, realized this might be something quite interesting to share, but first had to check that it's not something that has already been done. Long story short, the most relevant piece of research I was pointed to was "Backtracking, interleaving and terminating monad transformers", by O Kiselyov, C Shan, DP Friedman and A Sabry, published in 2005. (https://dl.acm.org/citation.cfm?id=1086390) I also know that this approach is embodied in Haskell through the Control.Monad.Logic library. I read the paper and skimmed through some related work, and gave a try to the library. Indeed, it seems to be doing mostly what I need. In particular, it can deal with infinite breadth/infinite width searches through a process of what I call "diagonalization". That is, a combination of breadth-first and depth-first that ensures fairness. Note that the library actually does a lot more things that I didn't consider because they were not relevant for my problem, for instance cuts. However, I find that there is something that this library does not take into account, and after trying with the Haskell library I have verified that indeed it does not work, whereas my library does work. I am wondering if I have overlooked some work in which this is also taken into account or if I may be onto some useful extension of Control.Monad.Logic that hasn't been done yet. I still have to find a stable name for the feature that I am talking about, but I usually refer to it as "step-wise termination" or "quantization of computations". To understand it consider an example (that I have actually implemented): 1. Whenever I have a non-deterministic enumeration, I should have a way to output a fair search among that non-deterministic search (a list), following the properties that I indicated above. 2. I can make an enumeration that non-deterministically produces all multiples of a certain number. 3. I can make an enumeration that non-deterministically produces all powers of a certain number. 4. I can make a function that, given an enumeration, filters it through a boolean function. 5. I can monadically combine computations, so that I can, for instance, produce a computation that is the result of producing all multiples of a number, and for each of those, producing all their powers. 6. So what happens if I combine the three of them. In particular, what if I output all *odd* powers of all multiples of 1 (all naturals)? (multiples 1) >>= (\x -> filter odd (powers x))? If I do this using the Control.Monad.Logic library (and using the >>- operator provided there, of course), this does not produce a fair search. Specifically, it outputs 1 and then hangs up. The reason? The order in which the search is produced picks one value from each sublist at a time, but because there are no odd powers of an even number (say 2), it never finds any element in the sublist of powers of 2, and therefore never gets to even try with the powers of 3. My library can deal with this by "quantizing" computation, making sure that each individual step of a computation always terminates (in Haskell terms, I wrap things up in a way that I can guarantee that a single look-ahead on the list will always produce a head normal form in finite time, even if that is still a continuation of the computation). Therefore, while it keeps trying to find powers of 2 that are odd, this does not stop the search over all the other sublists. This mail is already quite long, but let me make a few precisions. You may stop reading here if you don't wanna get your hands dirty, I've said the most important bits. I know a bit of what I say here will be confusing if you don't think about it yourself, so skip it if it gets confusing. It's mainly to answer some questions/comments I can foresee. Of course, this only works if the embedding into the monad is terminating itself. So, when you do "pure x" for my monad, you need to guarantee that "x" will produce a head normal form in finite time). But as long as you guarantee this atomic notion and you only use the monadic transformation functions that are not labelled as "unsafe" (which are only the unnatural ones for the semantics that I am considering, such as appending in a list sense), then I can guarantee the search will always be fair. Also, a thing I've been thinking quite a bit is whether you can consider this notion of "quantization" of computation separately from the notion of an enumeration of a non-deterministic search space. Of course you can, but the interesting bit is to do this diagonalization over non-deterministic search spaces in a quantized way so that rabbit holes like the odd powers of 2 are not a problem. I tried to implement this in a generic way that you can later on "combine" with Control.Monad.Logic in a non-specific way, but it won't work, due to the particular reason that you'd need to do pattern matching over the structure of the logic monad, and there's no way to type check that for an arbitrary data type (because the pattern matching could give literally any potential sub-types). Implementing the quantization separately and then the combination individually as a one-of thing could be done, of course, but it would essentially be the same that I have right now. A different story would be had if ghci actually had monadic functions to enable the evaluation of *any* thunk one-step-at-a-time (that is, one function evaluation or one pattern match). This is absolutely not what seq does, because seq evaluates until it is a weak head normal form, which is not what I want. Precisely, bottom seq a = bottom, and my quantized computation does not fulfill this equation (and it should not). My library is not perfect now, and after having read and understood the Control.Monad.Logic library, I think the best thing would be to extend it, which is something I don't do right now. But still so, unless I have missed an already existing implementation of something like this, or I am seeing something in a really convoluted way. Please feel free to drop any questions or comments at all. I'm attaching an example of why Control.Monad.Logic does not work in the case that I said. It also includes an example using my library, which I am not attaching. This example works. Just comment it. I'm not attaching my library now because it's not "polished" and because it is a lot for people to randomly look at, but feel free to ask for it and I'll happily send it over, so that you can run the example with it. Again, any questions or comments are welcome. Lead me the right direction with this. ... And sorry for the wall of text. Thank you very much for all of your time and attention, Juan Casanova. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 3

Hidden types and scope
by Lana Black 11 Jul '19

11 Jul '19

Hello cafe, While writing some code, I stumbled upon quite an interesting behavior. See the code example below. ------------------------------------------------------------- {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} data Wrapper = forall m. Monad m => Wrapper { runAction :: forall a. m a -> IO a , someAction :: String -> m () } newtype MyIO a = MyIO { runIO :: IO a } deriving (Monad) ex :: Wrapper ex = Wrapper runIO (\s -> MyIO (putStrLn s)) {- This doesn't work -} --main :: IO () --main = do let Wrapper r a = ex -- r (a "Hello") {- This works -} main :: IO () main = case ex of Wrapper r a -> r (a "Hello") ------------------------------------------------------------- The idea is to hide the exact type `m` used in the wrapper, making the wrapper somewhat opaque to the user, while exposing some functionality and making sure that using `runAction` with the rest of the members of Wrapper is type-safe and `m` is always the same type within one instance of Wrapper. The problem that I ran into is that the first version of `main` doesn't compile with the following error: • Couldn't match expected type ‘p’ with actual type ‘forall a. m a -> IO a’ because type variable ‘m’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: Wrapper :: forall (m :: * -> *). Monad m => (forall a. m a -> IO a) -> (String -> m ()) -> Wrapper, in a pattern binding at wildcards.hs:18:15-25 • In the pattern: Wrapper r a In a pattern binding: Wrapper r a = ex In the expression: do let Wrapper r a = ex r (a "Hello") This is repeated for every member of Wrapper that is matched in a let expression. However, if let expression is replaced with case, everything builds and works just fine. Is there a way to make it work with let expressions? That way the code is a lot cleaner, especially with RecordWildCards involved.

4 5

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 6
by Information The FLOSS 11 Jul '19

11 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

[ldap-client] Project takeover initiation
by Brian C. Jones 10 Jul '19

10 Jul '19

Hello, I have attempted to contact the author via PR and direct email with no response in 3 weeks. This is my final attempt before engaging the Hackage admins. https://github.com/supki/ldap-client/pull/16 Brian Jones

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 5
by Information The FLOSS 10 Jul '19

10 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

The GHC Committee welcomes its new members
by Joachim Breitner 10 Jul '19

10 Jul '19

Dear Haskell community, the GHC Steering committee welcomes its new two members, Sandy Maguire and Arnaud Spiwack. We are happy to see that there is continued interest in our work, and are looking forward to the insights and energy that are brought to the committee by Sandy and Arnaud. They take the seats of Ben Gamari and Manuel Chakravarty. A big thanks to Ben and Manuel for their contributions to GHC and the proposal committee. In particular Ben, who created the initials draft of the proposal process. We had four nominations in total, and I would like to preserve their privacy. Since we only had two seats to fill, we had to make a pick; nevertheless I am grateful for all nominations, and encourage everyone, including those who did not make it this time, to try again next time. Neither the committee nor its process is perfect, as the way two recent proposals went show, but we are constantly trying to refine and improve. Your feedback is always welcome, either at the committee mailing list, or in private communication with the Chairs (the two Simons), me, or any other member. On behalf of the committee, Joachim Breitner PS: Sandy and Arnaud, please subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

mapM and Control.Arrow
by Olaf Klinke 09 Jul '19

09 Jul '19

Dear cafe, consider the declaration mapM :: (SomeArrow a, Traversable t) => a b c -> a (t b) (t c) For the Arrow a = (->), the above mapM is just an over-constrained fmap, since Functor is a superclass of Traversable. For the arrow a = Kleisi m, the above mapM is the Control.Monad.mapM we know. Currently I fail to see how it could be defined with any of the existing sub-classes in Control.Arrow. One might say that fmap and mapM are on the same spectrum: If you specialize SomeArrow to (->) you can generalize Traversable to Functor, if you specialize Functor to Traversable you can generalize (->) to SomeArrow. Cheers, Olaf

2 3

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 4
by Information The FLOSS 09 Jul '19

09 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

parallel Haskell with limited sparks
by Henning Thielemann 09 Jul '19

09 Jul '19

When I read about parallel programming in Haskell it is always about manual chunking of data. Why? Most of my applications with parallelization benefit from a different computation scheme: Start a fixed number of threads (at most the number of available computing cores) and whenever a thread finishes a task it gets assigned a new one. This is how make -j, cabal install -j, ghc -j, work. I wrote my own package pooled-io which does the same for IO in Haskell and there seem to be more packages that implemented the same idea. Can I have that computation scheme for non-IO computations, too? With Parallel Strategies, monad-par etc.?

2 3

{-# SPECIALIZE foo @Bar #-} ?
by Johannes Waldmann 08 Jul '19

08 Jul '19

Dear Cafe, with pragma SPECIALIZE, I find it tedious to repeat the type declaration. (It's a burden for maintenance and readability.) Could we use type-application syntax instead? E.g., the example from here https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… hammeredLookup :: Ord key => [(key, value)] -> key -> value {-# SPECIALIZE hammeredLookup :: [(Widget, value)] -> Widget -> value #-} would become hammeredLookup :: forall key value . Ord key => [(key, value)] -> key -> value {-# SPECIALIZE hammeredLookup @Widget #-} or {-# SPECIALIZE hammeredLookup @Widget @value #-} Cf. SPECIALIZE instance, where we already write the instantiation for the type variable(s). - J.W.

2 1

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 3
by Information The FLOSS 08 Jul '19

08 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

Call for Participation: Summer BOB 2019 (August 21, Berlin)
by Stefan Wehr 08 Jul '19

08 Jul '19

======================================================================== Summer BOB 2019 Conference “What happens if we simply use what’s best?” August 21, 2019, Berlin co-located with ICFP 2019 http://bobkonf.de/2019-summer/ Program: http://bobkonf.de/2019-summer/program.html Registration: http://bobkonf.de/2019-summer/registration.html ======================================================================== Are you interested in technologies beyond the mainstream, that are a pleasure to use, and effective at getting the job done? BOB is the forum for developers, architects and builders to explore and discover the best tools available today for building software. Our goal is for all participants to leave the conference with new ideas to improve development back at the ranch. Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. BOB features two tracks of seven talk each: One research track with invited talks, and one track by practitioners, designed to cross-pollinate and inspire. http://bobkonf.de/2019-summer/program.html Topics include distributed programming, testing, linear algebra, functional design patterns, type systems, formal methods, and interactive development. We are committed to diversity: We aim at exploring a wide range of tools in a welcoming and friendly crowd of diverse people. To that end, a number of support options for participants from groups under-represented in tech are available. http://bobkonf.de/2019-summer/registration.html NOTE: The early-bird rates expire on July 18, 2019!

1 0

Help wanted getting old GADT code to compile
by nr＠cs.tufts.edu 05 Jul '19

05 Jul '19

Here is a legacy file that does not compile with GHC 8.0.1: {-# LANGUAGE RankNTypes, GADTs, KindSignatures #-} module Bookgadt where data TExp :: * -> * where TLit :: (forall a . (a -> (TExp a))) TLit' :: (a -> (TExp a)) The compiler rejects value constructor TLit with this error message: • Data constructor ‘TLit’ returns type ‘forall a. a -> TExp a’ instead of an instance of its parent type ‘TExp a’ I really want to keep the explicit "forall," as I'm trying to make a point for readers not familiar with Haskell. Does anyone know if there is some option or other incantation that would enable this code to compile? Norman

3 2

The future of the SPARC NCG backend
by Ben Gamari 01 Jul '19

01 Jul '19

Hello everyone, If you use (or think you might use in the future) GHC's SPARC NCG backend please do leave a note on #16882 [1]. My impression is that it has no users and no plausible means of testing. Consequently I am suggesting that we remove it in GHC 8.12. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/16882

1 0

NB: DO NOT USE `pure = return`
by Johannes Waldmann 01 Jul '19

01 Jul '19

Dear Cafe, the migration guide (for AMP) https://gitlab.haskell.org/ghc/ghc/wikis/migration/7.10#ghc-says-no-instanc… contains this advice: instance Applicative Foo where -- NB: DO NOT USE `pure = return` Why not? Because it would require another refactoring once "monad of no return" comes true? So defining `return` in the Monad instance should work fine until then? Which is when exactly? I can't quite make it out from https://gitlab.haskell.org/ghc/ghc/wikis/proposal/monad-of-no-return/discus… - J.W.

2 1

Call For Papers: Workshop in OCL and Textual Modeling (OCL 2019)
by Achim D. Brucker 29 Jun '19

29 Jun '19

CALL FOR PAPERS 19th International Workshop on OCL and Textual Modeling Co-located with MODELS 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and System, September 15-20, 2019, Munich, Germany http://oclworkshop.github.io The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages (e.g., OCL, textual MOF, Epsilon, or Alloy) can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Submissions Four types of submissions will be considered: * Presentation only submission (not included in the workshop proceedings), e.g., for already published work. Authors should submit a short (1 page) abstract of their presentation. * Short papers (between 5 and 7 pages) describing new ideas or position papers. * Tool papers (between 5 and 7 pages) describing tools supporting textual modeling tools * Full papers (between 10 and 14 pages). All submissions should follow the LNCS format guidelines and should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2019). Accepted papers will be published online in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: 14 Jul 2019 - Notification: 25 Aug 2019 - Pre-Workshop CRC: 9 Sep 2019 - Post-Workshop CRC: 5 Oct 2019 -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Intention to take over package "quipper"
by selinger＠mathstat.dal.ca 27 Jun '19

27 Jun '19

I am writing, as recommended at https://wiki.haskell.org/Taking_over_a_package, to announce my intention to take over the "quipper" package on Hackage. I have contacted the author (miniBill, aka Leonardo Taglialegne) in February 2019, and again this Tuesday, with no response. I am one of the authors of Quipper, and the code in miniBill's "quipper" package was actually written by me and my coauthors. Since the package is both outdated and incomplete, and he is not maintaining it, we would like to assume ownership of the package. Thanks, -- Peter

1 0

Reshaping arrays in accelerate
by Lana Black 27 Jun '19

27 Jun '19

Hello cafe, Is there a generic way to reshape an array in accelerate[1] assuming the number of dimensions remains constant? For example, given a matrix, is there a way to add or, more importantly, remove several rows or columns? It seems to me that the API is lacking in this case, but I hope I'm wrong. Thank you. [1]: https://hackage.haskell.org/package/accelerate-1.2.0.1/

2 1

Re: [Haskell-cafe] extra semi-colons
by Johannes Waldmann 26 Jun '19

26 Jun '19

> The rule "alt" allows "(empty alternative)" Ah, yes. But no? The standard says > A case expression must have at least one alternative > and each alternative must have at least one body. Should this be "each non-empty alternative must have ..."? I think the intention is to allow case () of () | False -> () | True -> () (one alternative, two bodies) but to disallow case () of () (one alternative, no body) - J.

2 2

Unexpected result from Data.Compact.inCompact?
by Viktor Dukhovni 26 Jun '19

26 Jun '19

I am seeing surprising results from 'inCompact' after 'compact'. It seems there are additional limitations on what can be compacted, with 'compact' not throwing a 'CompactionFailed' exception in some cases, and yet not compacting the value. Is this expected? When the below is compiled and run: {-# LANGUAGE OverloadedStrings #-} module Main (main) where import Data.Compact import qualified Data.ByteString.Short as S import qualified Data.Map.Strict as M fib :: [Int] fib = 0:1:zipWith (+) fib (tail fib) u = if M.lookup 3 m == Just 2 then () else undefined f3 = head $ drop 3 fib m = M.fromList $ zip [0..9] fib main :: IO () main = do test "explicit ()" () test "computed ()" u test "explicit Int" (42 :: Int) test "computed Int" f3 test "empty string" ("" :: String) test "non-empty string" ("some string" :: String) test "empty short bytestring" S.empty test "non-empty short bytestring" (S.toShort "some bytestring") test "explict empty map" (M.empty :: M.Map Int Int) test "computed fib table" m where test :: String -> a -> IO () test msg val = do putStr (msg ++ ": ") c <- compact val inCompact c (getCompact c) >>= print it outputs: explicit (): False computed (): False explicit Int: False computed Int: True empty string: False non-empty string: True empty short bytestring: True non-empty short bytestring: True explict empty map: False computed fib table: True but the documentation promises: getCompact :: Compact a -> a # Retrieve a direct pointer to the value pointed at by a Compact reference. If you have used compactAdd, there may be multiple Compact references into the same compact region. Upholds the property: inCompact c (getCompact c) == True so when 'compact' does not bottom, I'd expect 'True'. -- Viktor.

2 1

OT: CLR and JVM
by trent shipley 26 Jun '19

26 Jun '19

Is there a typed, functional language with mature versions on Microsoft's CLR and the JVM? A JVM OCaml to go with F# would be ideal. Trent

1 0

(Extended deadline) Formal Methods 2019 - 1st Workshop on Formal Methods for Blockchains, CFP
by Bruno Bernardo 25 Jun '19

25 Jun '19

[ Please distribute, apologies for multiple postings. ] ========================================================== 1st Workshop on Formal Methods for Blockchains (FMBC) 2019 https://sites.google.com/view/fmbc/home Porto, Portugal, October 11 Part of the 3rd World Congress on Formal Methods http://formalmethods2019.inesctec.pt/ ------------------------------------------------------------- IMPORTANT DATES -------------------------------- Abstract submission: June 30, 2019 (extended) Full paper submission: July 7, 2019 (extended) Notification: July 31, 2019 Camera-ready: September 2, 2019 Conference: October 11, 2019 -------------------------------- -------------------------------- TOPICS OF INTEREST -------------------------------- Blockchains are decentralized transactional ledgers that rely on cryptographic hash functions for guaranteeing the integrity of the stored data. Participants on the network reach agreement on what valid transactions are through consensus algorithms. Blockchains may also provide support for Smart Contracts. Smart Contracts are scripts of an ad-hoc programming language that are stored in the blockchain and that run on the network. They can interact with the ledger’s data and update its state. These scripts can express the logic of possibly complex contracts between users of the blockchain. Thus, Smart Contracts can facilitate the economic activity of blockchain participants. With the emergence and increasing popularity of cryptocurrencies such as Bitcoin and Ethereum, it is now of utmost importance to have strong guarantees of the behavior of blockchain so ware. These guarantees can be brought by using Formal Methods. Indeed, Blockchain software encompasses many topics of computer science where using Formal Methods techniques and tools are relevant: consensus algorithms to ensure the liveness and the security of the data on the chain, programming languages specifically designed to write smart contracts, cryptographic protocols, such as zero-knowledge proofs, used to ensure privacy, etc. This workshop is a forum to identify theoretical and practical approaches of formal methods for blockchain technology. Topics include, but are not limited to: * Design and implementation of Smart Contract languages * Formal models of blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for blockchain-specific cryptographic primitives or protocols Formal languages for Smart * Verification of Smart Contracts -------------------------------- -------------------------------- SUBMISSION -------------------------------- Submit original manuscripts (not published or considered elsewhere) with a maximum of twelve pages (regular papers), six pages (short papers), and two pages (extended abstract) describing new and emerging ideas or summarizing existing work). Each paper should include a title and the name and affiliation of each author. Authors of selected extended-abstracts are invited to give a short lightning talk of up to 15 minutes. At least one author of an accepted paper is expected to present the paper at the workshop as a registered participant. All accepted contributions will be reviewed once more by the program committee after the workshop and before being included in the post-proceedings. submission link https://easychair.org/conferences/?conf=fmbc19 -------------------------------- -------------------------------- PROCEEDINGS -------------------------------- All submissions will be peer-reviewed by at least three members of the program committee for quality and relevance. Accepted regular papers (full and short papers) will be included in the FM workshop post-proceedings, published as a volume of the Lecture Notes in Computer Science (LNCS) by Springer. -------------------------------- -------------------------------- INVITED SPEAKER --------------------------------------------------------------------------------------------------------- Ilya Sergey - Associate Professor at Yale-NUS College and NUS School of Computing, (Singapore). --------------------------------------------------------------------------------------------------------- -------------------------------- -------------------------------- PROGRAM committee -------------------------------- Program Chairs Bruno Bernardo (bruno(a)nomadic-labs.com <mailto:bruno@nomadic-labs.com>) Néstor Cataño (nestor.catano(a)gmail.com <mailto:nestor.catano@gmail.com>) Diego Marmsoler (diego.marmsoler(a)tum.de <mailto:diego.marmsoler@tum.de>) Program Committee Pietro Abate (Nomadic Labs, France) Ijaz Ahmed (University of Madeira, Portuga) Jonathan Aldrich (Carnegie Mellon University, USA) Bernhard Beckert (Karlsruhe Institute of Technology, Germany) Bruno Bernardo (Nomadic Labs, France) Sukriti Bhattacharya (LIST, Luxembourg) Néstor Cataño (Universidad del Norte, Colombia) Maria Christakis (MPI-SWS, Germany) Léa-Zaynah Dargaye (CEA LIST, France) Georges Gonthier (Inria, France) Neville Grech (University of Athens, Greece / University of Malta, Malta) Davide Grossi (University of Groningen, Netherlands) Sorren Hanvey (Liverpool John Moores University, UK) Andreas Lochbihler (Digital Asset, Swiss) Diego Marmsoler (Technische Universitat Munchen, Germany) Anastasia Mavridou (NASA Ames, USA) Simão Melo de Sousa (Universidade da Beira Interior, Portugal) Fabio Mogavero (Università degli Studi di Napoli, Italy) Peter Csaba Ölveczky (University of Oslo, Norway) Karl Palmskog (University of Texas at Austin, USA) Vincent Rahli (University of Luxembourg, Luxembourg) Steve Reeves (University of Waikato, New Zealand) Camilo Rueda (Pontificia Universidad Javeriana, Colombia) Claudio Russo (Dfinity Foundation, USA) Jorge Sousa Pinto (Universidade do Minho, Portugal) Bas Spitters (Aarhus University, Denmark) Christoph Sprenger (ETH, Zürich) Mark Staples (Data61, Australia) Philip Wadler (University of Edinburgh / IOHK, UK) Xi Wu (The University of Queensland, Australia) Santiago Zanella-Beguelin (Microsoft Research Cambridge, UK) --------------------------------

1 0

extra semi-colons
by Johannes Waldmann 25 Jun '19

25 Jun '19

Dear Cafe, why does ghc accept the extra semi-colon in case () of { () -> (); } or even case () of { ;;; () -> () ;;; } Yes I understand that semicolons like this are introduce by the layout rule L (<n> : ts) (m : ms) = ; : (L ts (m : ms)) if m = n https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800… and it's convenient to ignore extra ones. But it's not in the grammar? alts → alt1 ; … ; altn (n ≥ 1) https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.… - J.

2 1

Call for Participation: ICFP 2019
by Sam Tobin-Hochstadt 24 Jun '19

24 Jun '19

===================================================================== Call for Participation ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 18 - August 23, 2019 Berlin, Germany http://icfp19.sigplan.org/ Early Registration until July 18! ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. This year, ICFP is co-located with BOBKonf! * Overview and affiliated events: http://icfp19.sigplan.org/home * Program: http://icfp19.sigplan.org/program/program-icfp-2019 * Accepted papers: http://icfp19.sigplan.org/track/icfp-2019-papers * Registration is available via: https://regmaster4.com/2019conf/ICFP19/register.php Early registration ends 18 July, 2019. * Programming contest: https://icfpcontest2019.github.io/ * Student Research Competition: https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference In addition to BOBKonf (8/21), there are several events co-located with ICFP: * Erlang Workshop (8/18) * Functional Art, Music, Modeling and Design (8/23) * Functional High-Performance and Numerical Computing (8/18) * Haskell Implementors' Workshop (8/23) * Haskell Symposium (8/22-8/23) * miniKanren Workshop (8/22) * ML Family Workshop (8/22) * OCaml Workshop (8/23) * Programming Languages Mentoring Workshop (8/18) * Scheme Workshop (8/18) * Type-Driven Development (8/18) ### ICFP Organizers General Chair: Derek Dreyer (MPI-SWS, Germany) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Ilya Sergey (Yale-NUS College, Singapore) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: William J. Bowman (University of British Columbia, Canada) Workshops Co-Chair: Christophe Scholliers (Universiteit Gent, Belgium) Jennifer Hackett (University of Nottingham, UK) Conference Manager: Annabel Satin (P.C.K.) ### PACMPL Volume 3, Issue ICFP 2019 Principal Editor: François Pottier (Inria, France) Review Committee: Lennart Beringer (Princeton University, United States) Joachim Breitner (DFINITY Foundation, Germany) Laura M. Castro (University of A Coruña, Spain) Ezgi Çiçek (Facebook London, United Kingdom) Pierre-Evariste Dagand (LIP6/CNRS, France) Christos Dimoulas (Northwestern University, United States) Jacques-Henri Jourdan (CNRS, LRI, Université Paris-Sud, France) Andrew Kennedy (Facebook London, United Kingdom) Daan Leijen (Microsoft Research, United States) Kazutaka Matsuda (Tohoku University, Japan) Bruno C. d. S. Oliveira (University of Hong Kong, China) Klaus Ostermann (University of Tübingen, Germany) Jennifer Paykin (Galois, United States) Frank Pfenning (Carnegie Mellon University, USA) Mike Rainey (Indiana University, USA) Chung-chieh Shan (Indiana University, USA) Sam Staton (University of Oxford, UK) Pierre-Yves Strub (Ecole Polytechnique, France) German Vidal (Universitat Politecnica de Valencia, Spain) External Review Committee: Michael D. Adams (University of Utah, USA) Robert Atkey (University of Strathclyde, IK) Sheng Chen (University of Louisiana at Lafayette, USA) James Cheney (University of Edinburgh, UK) Adam Chlipala (Massachusetts Institute of Technology, USA) Evelyne Contejean (LRI, Université Paris-Sud, France) Germán Andrés Delbianco (IRIF, Université Paris Diderot, France) Dominique Devriese (Vrije Universiteit Brussel, Belgium) Richard A. Eisenberg (Bryn Mawr College, USA) Conal Elliott (Target, USA) Sebastian Erdweg (Delft University of Technology, Netherlands) Michael Greenberg (Pomona College, USA) Adrien Guatto (IRIF, Université Paris Diderot, France) Jennifer Hackett (University of Nottingham, UK) Troels Henriksen (University of Copenhagen, Denmark) Chung-Kil Hur (Seoul National University, Republic of Korea) Roberto Ierusalimschy (PUC-Rio, Brazil) Ranjit Jhala (University of California, San Diego, USA) Ralf Jung (MPI-SWS, Germany) Ohad Kammar (University of Oxford, UK) Oleg Kiselyov (Tohoku University, Japan) Hsiang-Shang ‘Josh’ Ko (National Institute of Informatics, Japan) Ondřej Lhoták (University of Waterloo, Canada) Dan Licata (Wesleyan University, USA) Geoffrey Mainland (Drexel University, USA) Simon Marlow (Facebook, UK) Akimasa Morihata (University of Tokyo, Japan) Shin-Cheng Mu (Academia Sinica, Taiwan) Guillaume Munch-Maccagnoni (Inria, France) Kim Nguyễn (University of Paris-Sud, France) Ulf Norell (Gothenburg University, Sweden) Atsushi Ohori (Tohoku University, Japan) Rex Page (University of Oklahoma, USA) Zoe Paraskevopoulou (Princeton University, USA) Nadia Polikarpova (University of California, San Diego, USA) Jonathan Protzenko (Microsoft Research, USA) Tiark Rompf (Purdue University, USA) Andreas Rossberg (Dfinity, Germany) KC Sivaramakrishnan (University of Cambridge, UI) Nicholas Smallbone (Chalmers University of Technology, Sweden) Matthieu Sozeau (Inria, France) Sandro Stucki (Chalmers | University of Gothenburg, Sweden) Don Syme (Microsoft, UK) Zachary Tatlock (University of Washington, USA) Sam Tobin-Hochstadt (Indiana University, USA) Takeshi Tsukada (University of Tokyo, Japan) Tarmo Uustalu (Reykjavik University, Iceland) Benoit Valiron (LRI, CentraleSupelec, Univ. Paris Saclay, France) Daniel Winograd-Cort (University of Pennsylvania, USA) Nicolas Wu (University of Bristol, UK)

1 0

How long does it take to add an entry to https://www.haskell.org/community/?
by Benjamin L. Russell 23 Jun '19

23 Jun '19

Twenty-three days ago, I added an entry to the list of Haskell communities at https://www.haskell.org/community/ and submitted a pull request to have the page (https://github.com/haskell-infra/www.haskell.org/blob/master/community.mark…) updated; however, the page still has not been updated. In addition, it seems that there are 3 other pull requests for the same page by other users that have also not been applied, the earliest of which dates from March 16. How long does it take to add an entry to https://www.haskell.org/community/? (I'm assuming that submitting a pull request to "Update community.markdown" on Github is the correct procedure for those users without write access to the page.) -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Computer Science Document Translator/Editor "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

1 0

Munich Haskell Meeting, 2019-06-25 @ 19:30
by Leah Neukirchen 23 Jun '19

23 Jun '19

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 25 at **Hirschgarten (self-service area)** at 19h30. The weather should be nice! For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jun-2019/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1-alpha2 is now available
by Ben Gamari 22 Jun '19

22 Jun '19

George Colpitts <george.colpitts(a)gmail.com> writes: > Will 8.8.1 use llvm 7.0.1? I don't see it mentioned in the release notes. > Yes, this release will target LLVM 7. I'll add a mention to the release notes. Cheers, - Ben

1 0

HiW'19: Call for Talks
by Niki Vazou 21 Jun '19

21 Jun '19

Hey all, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP it is an ideal place to describe a Haskell library, a Haskell extension, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Deadline is June 28th. Call for Talks The 11th Haskell Implementors’ Workshop is to be held alongside ICFP 2019 this year in Berlin. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2019. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: - Compilation techniques - Language features and extensions - Type system implementation - Concurrency and parallelism: language design and implementation - Performance, optimization and benchmarking - Virtual machines and run-time systems - Libraries and tools for development or deployment Talks We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw19.hotcrp.com/ until June 28th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Invited Speakers - Lennart Augustsson & Satnam Singh Program Committee - Jose Calderon (Galois, Inc) - Jasper Van der Jeugt (Fugue) - Niki Vazou (IMDEA Software Institute) - Ningning Xie (The University of Hong King) - Brent Yorgey (Hendrix College) Best, Niki Vazou

1 1

ANN: network-3.1.0.1
by Evan Borden 20 Jun '19

20 Jun '19

Hello, I'm happy to announce the release of network-3.1.0.1. This release includes a few maintenance changes. http://hackage.haskell.org/package/network-3.1.0.1 Contributors ============ * Evan Borden @eborden * Jack Kelly @endgame * Kazu Yamamoto @kazu-yamamoto * Leif Metcalf @leifmetcalf Changes ======= You can view the changes on github. https://github.com/haskell/network/releases/tag/v3.1.0.1 Thank you to network's contributors for their continued support. -- Evan Borden

1 0

functional languages - pretty good for students!
by Dennis Raddle 19 Jun '19

19 Jun '19

I've been doing computer science tutoring for a few years in languages like Java and Python. I started teaching a 10th grade student Elm recently. I'd like to use Haskell at some point, but because he likes websites and games, Elm seemed more apropos. What I'm discovering is that a functional language like Elm is fairly natural to him and he's learning quickly! Our lessons prior to Elm (including Python, Java, and JavaScript at this point) are extracurricular and he hasn't put much study in-between lessons, so his progress has been slow. I don't think he's developed many "programming muscles." But now, his progress in Elm is faster. One factor, I think, is how concise functional code is. He hasn't developed much "programmer's eye" up to now (by which I mean scanning a lot of code quickly) but Elm, being much shorter, is easier for him to grasp at a glance. He also thinks the algebraic data model is cool. He sees how it's related to classes and subclasses, but he appreciates how relatively simple it is. Mike

2 1

How to define classy lenses for polymorphic types that involve singletons?
by Peter Simons 18 Jun '19

18 Jun '19

Hi, I am trying to combine the lens library's 'makeClassy' feature with a type that's polymorphic over a singleton type: > {-# LANGUAGE DataKinds, FlexibleInstances, FunctionalDependencies, GADTs, > KindSignatures, RankNTypes, TemplateHaskell, TypeFamilies > #-} > > import Control.Lens > import Data.Singletons > import Data.Singletons.TH > > data Sex = Male | Female > deriving (Show, Eq, Ord, Bounded, Enum) > > genSingletons [''Sex] > > data Person (sex :: Sex) = Person { _name :: String, _email :: String } > deriving (Show, Eq) > > makeClassy ''Person Lens generates a class definition that looks sensible to me: class HasPerson a (sex :: Sex) | a -> sex where person :: Lens' a (Person sex) email :: Lens' a String name :: Lens' a String {-# MINIMAL person #-} Furthermore, I also need a type SomePerson to hide the phantom type so that I can store people of different sexes in the same container, i.e. [SomePerson]: > data SomePerson where > SomePerson :: Sing sex -> Person sex -> SomePerson > > fromPerson :: SingI sex => Person sex -> SomePerson > fromPerson p = SomePerson Sing p > > toPerson :: SomePerson -> (forall sex. Sex -> Person sex -> a) -> a > toPerson (SomePerson s p) f = f (fromSing s) p Here is where I've run into trouble. In theory, I should be able to make SomePerson an instance of HasPerson, define person :: Lens' SomePerson (Person sex) to access the Person type inside of it, and that would allow me to use 'name' and 'email' for SomePerson just the same as for Person. However, it seems impossible to define that function because it leaks the universally quantified 'sex', so function does not type-check. I have a somewhat awkward work-around that translates lenses on Person to SomePerson > somePerson :: (forall sex. Lens' (Person sex) a) -> Lens' SomePerson a > somePerson l = lens (\(SomePerson _ p) -> view l p) > (\(SomePerson s p) x -> SomePerson s (set l x p)) and that allows me to define: > type SomePerson' (sex :: Sex) = SomePerson > > instance HasPerson (SomePerson' sex) sex where > person = undefined -- cannot type check because 'sex' would leak > name = somePerson name > email = somePerson email I'm not particularly happy with that solution, though. Is there maybe a way to make this work such that I can avoid defining 'name' and 'email' manually? Or is there a clever alternative way to define HasPerson such a 'person' method for SomePerson is possible? Best regards Peter

2 2

Lenses and Nested Maps
by Henry Laxen 18 Jun '19

18 Jun '19

Hi Cafe, Suppose I have: s :: Map String (Map Int Char) s = M.fromList [("alice", M.fromList [(5,'a')]), ("bob", M.fromList [(6,'b')])] Is there any way to modify the 'b' entry easily using lenses? Thanks in advance. Best wishes, Henry Laxen

4 3

[ANNOUNCE] GHC 8.8.1-alpha2 is now available
by Ben Gamari 17 Jun '19

17 Jun '19

Hello everyone, The GHC team is pleased to announce the second and likely last alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha2 A draft of the release notes is also available [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: * 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 * 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 * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release brings a number of fixes since alpha 1: * A number of linker fixes (#16779, #16784) * The process, binary, Cabal, time, terminfo libraries have all been bumped to their final release versions * A regression rendering TemplateHaskell unusable in cross-compiled configurations has been fixed (#16331) * A regression causing compiler panics on compilation of some programs has been fixed (#16449) * -Wmissing-home-modules now handles hs-boot files correctly (#16551) * A regression causing some programs to fail at runtime has been fixed (#16066) Due to on-going work on our release and testing infrastructure this cycle is proceeding at a pace significantly slower than expected. However, we anticipate that this investment will allow us to release a more reliable, easier-to-install compiler on the planned six-month release cadence in the future. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-…

2 2

Deprecation cycle for classes
by Tom Ellis 16 Jun '19

16 Jun '19

I am unsure how to change the name of a class in a library whilst providing a safe deprecation cycle for the users of the library. Suppose I have version 1 of my library with a class -- Version 1 class Foo a where foo :: a and I want to migrate it to version 3 as follows, but with a deprecation cycle provided by version 2 that allows code to work with either version 1 and 2, or 2 and 3. -- Version 3 class Bar a where bar :: a Then I can try to write version 2 as -- Version 2 {-# ConstraintKinds #-} class Foo a where bar :: a bar = foo foo :: a foo = bar type Bar = Foo This satisfies the following conditions: Users of versions 1 and 2 can use * The constraint Foo * The method foo * The class Foo and method foo for implementing their own instances User of versions 2 and 3 can use * The constraint Bar * The method bar * The method bar for implementing their own instances but they cannot jointly use * The *class* Bar for implementing their own instances (since Bar is not a class, just a Constraint) Is there any way I can write a version 2 that allows users to implement instances that work with both version 2 and version 3? Thanks, Tom

3 5

Posting Request
by Michelle Keppler 13 Jun '19

13 Jun '19

Hello, Could you please post the following to the Haskell Cafe email? Galois is hiring for a variety of roles <https://news.us10.list-manage.com/track/click?u=49a6a2e17b12be2c5c4dcb232&i…> Including but not limited to: Software Engineers/Researchers, Project Managers, Hardware Engineers, and a Software Integration Engineer. We collaborate with organizations like NASA, DARPA, and AWS to explore blue sky ideas and turn them into usable technology. Some of the things we’ve worked on in the past: Formal methods, static analysis, cryptographic algorithms, abstract interpretation, type theory, formal verification, reinforcement learning, autonomous systems assurance, communication security, cyber-deception for network defense, DDoS defense, provable hardware security, and statistical anomaly detection for detecting advanced persistent threats. We think working here is awesome; see lifeatgalois.com <https://news.us10.list-manage.com/track/click?u=49a6a2e17b12be2c5c4dcb232&i…> . Thank you, Michelle Keppler -- Michelle Keppler Human Resources Partner michelle(a)galois.com <michelle(a)galois.com> 571-510-0659 *I* *galois* *I * *GALOIS, INC.* 901 N Stuart Street *I* Suite 501 *I* Arlington, VA 22203 www.galois.com

1 0

ANN: stack-2.1.1 release
by Emanuel Borsboom 13 Jun '19

13 Jun '19

Announcing the first release in the stack-2.1 series! You can download bindists for all supported platforms from https://github.com/commercialhaskell/stack/releases/tag/v2.1.1 The Stack 2 release represents a series of significant changes to how Stack works internally. For the vast majority of cases, these changes are backwards compatible, in that existing projects will continue to build in the same way with Stack 2 as they did with Stack 1. The large version bump is due to the fundamental internal changes to cache handling, database storage (using SQLite in place of binary files), implicit snapshots (which greatly improve the precompiled cache), and moving to Pantry. We have also removed some less used features, as listed in the release notes below. **Changes since v1.9.3** Major changes: * Switch over to pantry for managing packages. This is a major change to Stack's internals, and affects user-visible behavior in a few places. Some highlights: * Drop support for multiple package indices and legacy `00-index.tar` style indices. See [#4137](https://github.com/commercialhaskell/stack/issues/4137). * Support for archives and repos in the `packages` section has been removed. Instead, you must use `extra-deps` for such dependencies. `packages` now only supports local filepaths. * Add support for Git repositories containing (recursive) submodules. * Addition of new configuration options for specifying a "pantry tree" key, which provides more reproducibility around builds, and (in the future) will be used for more efficient package content downloads. You can also specify package name and version for more efficient config parsing. * __NOTE__ The new `stack freeze` command provides support for automatically generating this additional information. * Package contents and metadata are stored in an SQLite database in place of files on the filesystem. The `pantry` library can be used for interacting with these contents. * Internally, Stack has changed many datatypes, including moving to Cabal's definition of many data types. As a result of such changes, existing cache files will in general be invalidated, resulting in Stack needing to rebuild many previously cached builds in the new version. Sorry :(. * A new command, `stack freeze` has been added which outputs project and snapshot definitions with dependencies pinned to their exact versions. * The `ignore-revision-mismatch` setting is no longer needed, and has been removed. * Overriding GHC boot packages results in any other GHC boot packages depending on it being no longer available as a dependency, such packages need to be added explicitly when needed. See [#4510] (https://github.com/commercialhaskell/stack/issues/4510) * Cabal solver integration was not updated to support newer `cabal-install` versions so `stack solver` command was removed as well as a related option `--solver` from `stack new` and `stack init`. * Upgrade to Cabal 2.4 * Note that, in this process, the behavior of file globbing has been modified to match that of Cabal. In particular, this means that for Cabal spec versions less than 2.4, `*.txt` will match `foo.txt`, but not `foo.2.txt`. * Remove the `stack image` command. With the advent of Docker multistage builds, this functionality is no longer useful. For an example, please see [Building Haskell Apps with Docker](https://www.fpcomplete.com/blog/2017/12/building-haskell-apps-with-…. * Support building GHC from source (experimental) * Stack now supports building and installing GHC from source. The built GHC is uniquely identified by a commit id and an Hadrian "flavour" (Hadrian is the newer GHC build system), hence `compiler` can be set to use a GHC built from source with `ghc-git-COMMIT-FLAVOUR` * `stack.yaml` now supports a `configure-options`, which are passed directly to the `configure` step in the Cabal build process. See [#1438](https://github.com/commercialhaskell/stack/issues/1438) * Remove support for building GHCJS itself. Future releases of Stack may remove GHCJS support entirely. * Support for lock files for pinning exact project dependency versions Behavior changes: * `stack.yaml` now supports `snapshot`: a synonym for `resolver`. See [#4256](https://github.com/commercialhaskell/stack/issues/4256) * `stack script` now passes `-i -idir` in to the `ghc` invocation. This makes it so that the script can import local modules, and fixes an issue where `.hs` files in the current directory could affect interpretation of the script. See [#4538](https://github.com/commercialhaskell/stack/pull/4538) * When using `stack script`, custom snapshot files will be resolved relative to the directory containing the script. * Remove the deprecated `--upgrade-cabal` flag to `stack setup`. * Support the `drop-packages` field in `stack.yaml` * Remove the GPG signing code during uploads. The GPG signatures have never been used yet, and there are no plans to implement signature verification. * Remove the `--plain` option for the `exec` family of commands * Always use the `--exact-configuration` Cabal configuration option when building (should mostly be a non-user-visible enhancement). * No longer supports Cabal versions older than `1.19.2`. This means projects using snapshots earlier than `lts-3.0` or `nightly-2015-05-05` will no longer build. * Remove the `stack docker cleanup` command. Docker itself now has [`docker image prune`](https://docs.docker.com/engine/reference/commandline/image_prune/) and [`docker container prune`](https://docs.docker.com/engine/reference/commandline/container_prun…, which you can use instead. * Interleaved output is now turned on by default, see [#4702](https://github.com/commercialhaskell/stack/issues/4702). In addition, the `packagename> ` prefix is no longer included in interelaved mode when only building a single target. * The `-fhide-source-paths` GHC option is now enabled by default and can be disabled via the `hide-source-paths` configuration option in `stack.yaml`. See [#3784](https://github.com/commercialhaskell/stack/issues/3784) * Stack will reconfigure a package if you modify your `PATH` environment variable. See [#3138](https://github.com/commercialhaskell/stack/issues/3138). * For GHC 8.4 and later, disable the "shadowed dependencies" workaround. This means that Stack will no longer have to force reconfigures as often. See [#3554](https://github.com/commercialhaskell/stack/issues/3554). * When building a package, Stack takes a lock on the dist directory in use to avoid multiple runs of Stack from trampling each others' files. See [#2730](https://github.com/commercialhaskell/stack/issues/2730). * Stack will check occassionally if there is a new version available and prompt the user to upgrade. This will not incur any additional network traffic, as it will piggy-back on the existing Hackage index updates. You can set `recommend-stack-upgrade: false` to bypass this. See [#1681](https://github.com/commercialhaskell/stack/issues/1681). * `stack list-dependencies` has been removed in favour of `stack ls dependencies`. * The new default for `--docker-auto-pull` is enabled. See [#3332](https://github.com/commercialhaskell/stack/issues/3332). Other enhancements: * Support MX Linux in get-stack.sh. Fixes [#4769](https://github.com/commercialhaskell/stack/issues/4769). * Defer loading up of files for local packages. This allows us to get plan construction errors much faster, and avoid some unnecessary work when only building a subset of packages. This is especially useful for the curator use case. * Existing global option `--color=WHEN` is now also available as a non-project-specific yaml configuration parameter `color:`. * Adopt the standard proposed at http://no-color.org/, that color should not be added by default if the `NO_COLOR` environment variable is present. * New command `stack ls stack-colors` lists the styles and the associated 'ANSI' control character sequences that stack uses to color some of its output. See `stack ls stack-colors --help` for more information. * New global option `--stack-colors=STYLES`, also available as a non-project-specific yaml configuration parameter, allows a stack user to redefine the default styles that stack uses to color some of its output. See `stack --help` for more information. * British English spelling of 'color' (colour) accepted as an alias for `--color`, `--stack-colors`, `stack ls stack-colors` at the command line and for `color:` and `stack-colors:` in yaml configuration files. * New build option `--ddump-dir`. (See [#4225](https://github.com/commercialhaskell/stack/issues/4225)) * Stack parses and respects the `preferred-versions` information from Hackage for choosing latest version of a package in some cases, e.g. `stack unpack packagename`. * The components output in the `The main module to load is ambiguous` message now include package names so they can be more easily copy-pasted. * Git repos are shared across multiple projects. See [#3551](https://github.com/commercialhaskell/stack/issues/3551) * Use en_US.UTF-8 locale by default in pure Nix mode so programs won't crash because of Unicode in their output [#4095](https://github.com/commercialhaskell/stack/issues/4095) * Add `--tree` to `ls dependencies` to list dependencies as tree. [#4101](https://github.com/commercialhaskell/stack/issues/4101) * Add `--pedantic` to `ghci` to run with `-Wall` and `-Werror` [#4463](https://github.com/commercialhaskell/stack/issues/4463) * Add `--cabal-files` flag to `stack ide targets` command. * Add `--stdout` flag to all `stack ide` subcommands. * Use batches when unregistering packages with `ghc-pkg`. (See [#2662](https://github.com/commercialhaskell/stack/issues/2662)) * `get-stack` script now works on Windows CI machines of Appveyor, Travis and Azure Pipelines. See [#4535](https://github.com/commercialhaskell/stack/issues/4535)/ * Show snapshot being used when `stack ghci` is invoked outside of a project directory. See [#3651](https://github.com/commercialhaskell/stack/issues/3651) * The script interpreter now accepts a `--extra-dep` flag for adding packages not present in the snapshot. Currently, this only works with packages from Hackage, not Git repos or archives. * When using the script interpreter with `--optimize` or `--compile`, Stack will perform an optimization of checking whether a newer executable exists, making reruns significantly faster. There's a downside to this, however: if you have a multifile script, and change one of the dependency modules, Stack will not automatically detect and recompile. * `stack clean` will delete the entire `.stack-work/dist` directory, not just the relevant subdirectory for the current GHC version. See [#4480](https://github.com/commercialhaskell/stack/issues/4480). * Add `stack purge` as a shortcut for `stack clean --full`. See [#3863](https://github.com/commercialhaskell/stack/issues/3863). * Both `stack dot` and `stack ls dependencies` accept a `--global-hints` flag to bypass the need for an installed GHC. See [#4390](https://github.com/commercialhaskell/stack/issues/4390). * Add the `stack config env` command for getting shell script environment variables. See [#620](https://github.com/commercialhaskell/stack/issues/620). * Less verbose output from `stack setup` on Windows. See [#1212](https://github.com/commercialhaskell/stack/issues/1212). * Add an optional `ignore-expiry` flag to the `hackage-security` section of the `~/.stack/config.yaml`. It allows to disable timestamp expiration verification just like `cabal --ignore-expiry` does. The flag is not enabled by default so that the default functionality is not changed. * Include default values for most command line flags in the `--help` output. See [#893](https://github.com/commercialhaskell/stack/issues/893). * Set the `GHC_ENVIRONMENT` environment variable to specify dependency packages explicitly when running test. This is done to prevent ambiguous module name errors in `doctest` tests. * `get-stack` script now works on Windows CI machines of Appveyor, Travis and Azure Pipelines. See [#4535](https://github.com/commercialhaskell/stack/issues/4535) * Warn when a Docker image does not include a `PATH` environment variable. See [#2472](https://github.com/commercialhaskell/stack/issues/2742) * When using `system-ghc: true`, Stack will now find the appropriate GHC installation based on the version suffix, allowing you to more easily switch between various system-installed GHCs. See [#2433](https://github.com/commercialhaskell/stack/issues/2433). * `stack init` will now support create a `stack.yaml` file without any local packages. See [#2465](https://github.com/commercialhaskell/stack/issues/2465) * Store caches in SQLite database instead of files. * No longer use "global" Docker image database (`docker.db`). * User config files are respected for the script command. See [#3705](https://github.com/commercialhaskell/stack/issues/3705), [#3887](https://github.com/commercialhaskell/stack/issues/3887). * Set the `GHC_ENVIRONMENT` environment variable to `-` to tell GHC to ignore any such files when GHC is new enough (>= 8.4.4), otherwise simply unset the variable. This allows Stack to have control of package databases when running commands like `stack exec ghci`, even in the presence of implicit environment files created by `cabal new-build`. See [#4706](https://github.com/commercialhaskell/stack/issues/4706). * Use a database cache table to speed up discovery of installed GHCs * You can specify multiple `--test-arguments` options. See [#2226](https://github.com/commercialhaskell/stack/issues/2226) * Windows terminal width detection is now done. See [#3588](https://github.com/commercialhaskell/stack/issues/3588) * On Windows, informs users if the 'programs' path contains a space character and further warns users if that path does not have an alternative short ('8 dot 3') name, referencing the `local-programs-path` configuration option. See [#4726](https://github.com/commercialhaskell/stack/issues/4726) * Add `--docker-mount-mode` option to set the Docker volume mount mode for performance tuning on macOS. Bug fixes: * Ignore duplicate files for a single module when a Haskell module was generated from a preprocessor file. See [#4076](https://github.com/commercialhaskell/stack/issues/4076). * Only track down components in current directory if there are no hs-source-dirs found. This eliminates a number of false-positive warnings, similar to [#4076](https://github.com/commercialhaskell/stack/issues/4076). * Handle a change in GHC's hi-dump format around `addDependentFile`, which now includes a hash. See [yesodweb/yesod#1551](https://github.com/yesodweb/yesod/issues/1551) * Fix `subdirs` for git repos in `extra-deps` to match whole directory names. Also fixes for `subdirs: .`. See [#4292](https://github.com/commercialhaskell/stack/issues/4292) * Fix for git packages to update submodules to the correct state. See [#4314](https://github.com/commercialhaskell/stack/pull/4314) * Add `--cabal-files` flag to `stack ide targets` command. * Don't download ghc when using `stack clean`. * Support loading in GHCi definitions from symlinked C files. Without this patch, Stack will try to find object files in the directory pointed to by symlinks, while GCC will produce the object files in the original directory. See [#4402](https://github.com/commercialhaskell/stack/pull/4402) * Fix handling of GitHub and URL templates on Windows. See [commercialhaskell/stack#4394](https://github.com/commercialhaskell/stack/is… * Fix `--file-watch` not responding to file modifications when running inside docker on Mac. See [#4506](https://github.com/commercialhaskell/stack/issues/4506) * Using `--ghc-options` with `stack script --compile` now works. * Ensure the detailed-0.9 type tests work. See [#4453](https://github.com/commercialhaskell/stack/issues/4453). * Extra include and lib dirs are now order-dependent. See [#4527](https://github.com/commercialhaskell/stack/issues/4527). * Apply GHC options when building a `Setup.hs` file. See [#4526](https://github.com/commercialhaskell/stack/issues/4526). * Stack handles ABI changes in FreeBSD 12 by differentiating that version from previous. * Help text for the `templates` subcommand now reflects behaviour in stack 1.9 — that it downloads and shows a help file, rather than listing available templates. * Fix detection of aarch64 platform (this broke when we upgraded to a newer Cabal version). * Docker: fix detecting and pulling missing images with `--docker-auto-pull`, see [#4598](https://github.com/commercialhaskell/stack/issues/4598) * Hackage credentials are not world-readable. See [#2159](https://github.com/commercialhaskell/stack/issues/2159). * Warnings are dumped from logs even when color is enabled. See [#2997](https://github.com/commercialhaskell/stack/issues/2997) * `stack init` will now work for cabal files with sublibraries. See [#4408](https://github.com/commercialhaskell/stack/issues/4408) * When the Cabal spec version is newer than the global Cabal version, build against the snapshot's Cabal library. See [#4488](https://github.com/commercialhaskell/stack/issues/4488) * Docker: fix detection of expected subprocess failures. This fixes downloading a compatible `stack` executable when the host `stack` is not compatible with the Docker image (on Linux), and doesn't show an unnecessary extra error when the in-container re-exec'ed `stack` exits with failure. * The `stack ghci` command's `--ghc-options` flag now parses multiple options. See [#3315](https://github.com/commercialhaskell/stack/issues/3315). **Thanks to all our contributors for this release:** * Adam Bergmark * Akshay Mankar * Aleksey Kozin * ALeX Kazik * Alexey Kozin * Alexey Kuleshevich * Anders Kaseorg * Anders Kiel Hovgaard * Artyom Kazak * Bastian Krol * Björn Gohla * Brad Neimann * Brandon Chinn * Colin Woodbury * Cthulhu.Den * dadepo * Daniel Gröber * David Baynard * David Spies * David Vollbracht * dbaynard * Emanuel Borsboom * favonia * flip111 * Florjan Bartol * Gleb Popov * Hussein Ait-Lahcen * Isumi Feng * Janfel * Jurijs Oniscuks * Kayla Ngan * Kirill Zaborsky * Magicloud * Matt Audesse * Mauricio Fierro * Michael Sloan * Michael Snoyman * Mihai Maruseac * Mike Pilgrem * Neil Mitchell * NeonGraal * Niklas Hambüchen * penteract * Phil de Joux * Raghu Kaippully * Sibi * Sibi Prabakaran * Simon Hengel * skapazzo * Sylvain HENRY * Sylvain Henry * Taekyung * Timothy Clem * Tom Sydney Kerckhove * Valery V. Vorotyntsev * Vance Palacio * waddlaw * 欧阳泽

1 0

How to fix ambiguous type variable?
by Boris 13 Jun '19

13 Jun '19

Hi everyone, I was playing around with some tests and run into code that looks really similar to the following function someCheck :: (Show a, Read a, Eq a) => String -> a -> Bool someCheck s v = (read . show . read $ s) == v But obviously, it's not clear what instance to use in the right-most read and the show functions. So it doesn't compile. Out of curiosity, is it possible to make this function compile? I've struggled some time and could not find an answer by myself, so here I am. Thanks in advance! Cheers, boris(a)d12frosted.io

5 7

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 12 Jun '19

12 Jun '19

Dear Haskell community, the GHC Steering committee is seeking nominations for two or three new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until June 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Is there any place with nightly/master builds of GHC?
by Changlin Li 12 Jun '19

12 Jun '19

I'm interested in benchmarking GHC compile times (that is how long it takes GHC to compile a given file) on a more granular basis than official releases. It would be nice to save myself the hassle of re-building GHC across many different commits if there already was some archive of GHC builds (e.g. from master), even if it's a rolling archive over a short time window (e.g. per-week). Changlin

3 3

Final Call for Participation: Compose Conference [NYC, Jun 22- 23 2019]
by Gershom B 12 Jun '19

12 Jun '19

=============================================== Final Call for Participation Compose Conference 2019 Mon June 24 - Tue June 25 2019 (Unconference on Sat Jun 22 - Sun Jun 23) New York, NY Deadline for registration: June 14 at 11pm EST. http://www.composeconference.org/2019 =============================================== The practice and craft of functional programming :: Conference Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. Typed functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. It will feature a two days of great and wide-ranging talks * Invited Keynotes Donya Quick - Making Algorithmic Music David Spivak - Compositional Graphical Logic * Accepted Talks and Tutorials Kenny Foner - Functors of the World, Unite! Phillip Carter - The anatomy of the F# tools for Visual Studio Sebastien Mondet - Genspio: Generating Shell Phrases In OCaml Justin Le - Applicative Regular Expressions using the Free Alternative Gaetano Checinski - Buckaroo SAT - Solving a partially revealed SAT problem for Package Management Richard Feldman - From Rails to Elm and Haskell Samuel Gélineau - Stuck macros: deterministically interleaving macro-expansion and typechecking Vaibhav Sagar - Yes, IHaskell Can Do That! Fintan Halpenny - Bowl Full of Lentils Aditya Siram - A Tase Of ATS Ward Wheeler, Alex Washburn, Callan McGill - Phylogenetic Software in Haskell Igor Trindade Oliveira - Type Driven Secure Enclave Development using Idris David Christiansen - Bidirectional Type Checking Chris Smith - Teaching the intersection of mathematics and functional programming Brandon Kase - Fast Accumulation on Streams James Koppel - The Best Refactoring You’ve Never Heard Of Allister Beharry - Using Dependent Types in an F# DSL for Linear Algebra Diego Balseiro - Bridge Haskell and ReasonML in Production * Full abstracts: http://www.composeconference.org/2019/program * Conference Registration: https://www.eventbrite.com/e/new-york-compose-2019-tickets-56751182314 * Unconference Registration: https://www.eventbrite.com/e/new-york-compose-unconference-2019-tickets-603… * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at info(a)composeconference.org * Please forward this announcement to interested parties and lists.

1 0