- Haskell-Cafe - Haskell.org

[ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 14 Mar '18

14 Mar '18

The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Further refinement of TypeInType, including significant improvements in error messages. * Improvements in code generation resulting in noticable performance improvements in some types of programs. * Core library improvements, including phase 2 of the Semigroup/Monoid proposal * Many improvements to instance deriving * The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.… There are a few changes in release-engineering matters that should be noted, * This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. * While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. * FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

3 3

Append after index and update items after inserted item with lens
by Cody Goodman 13 Mar '18

13 Mar '18

Hello, I'm trying to insert a new elemnt into a list after a given index and increment the orderId accordingly with the lens library. I'm a bit confused at why this code isn't working: ``` import Control.Lens data A = A { _customOrderId :: Int } deriving Show things = [ A {_customOrderId = 0} , A {_customOrderId = 1} , A {_customOrderId = 2} , A {_customOrderId = 3} ] main = print $ things & ( (_drop 2 %~ ((A 22)<|)) . ((traversed . indices (> 2) . customerOrderIdLens) %~ (+ 1)) ) ``` The first portion works to insert where desired, but the second portion `((traversed . indices (> 2) . customerOrderIdLens) %~ (+ 1))` only increments the order id in indices 4. Any idea why this is happening? Thanks, Cody Goodman

2 2

Call for Contributions: Type-Driven Development 2018
by Niki Vazou 13 Mar '18

13 Mar '18

Hello, The first call for contributions for TyDe is out. Forward it to anyone who might be interested. Best, Niki Vazou ============================================== CALL FOR CONTRIBUTIONS Type 2018: Type-Driven Development https://icfp18.sigplan.org/track/tyde-2018 23-29 Sep, 2018, St. Louis, Missouri (co-located with ICFP) ============================================== *Call for Contributions* We welcome all contributions, both theoretical and practical, on a range of topics including: dependently typed programming; generic programming; design and implementation of programming languages, exploiting types in novel ways; exploiting typed data, data dependent data, or type providers; static and dynamic analyses of typed programs; tools, IDEs, or testing tools exploiting type information; pearls, being elegant, instructive examples of types used in the derivation, calculation, or construction of programs. *Important Dates* Regular paper deadline: Wednesday, June 6, 2018 Extended abstract deadline: Wednesday, June 13, 2018 Author notification: Friday, June 29, 2018 Deadline for camera ready version: August 5, 2018 Workshop: Thursday, September 27, 2018 *Program Committee* - Guillaume Allais, Radboud University Nijmegen, Netherlands - Zena M. Ariola, University of Oregon, USA - David Darais, University of Vermont, USA - Richard Eisenberg, Bryn Mawr College, USA (co-chair) - Jennifer Hackett, University of Nottingham, UK - Shin-ya Katsumata, National Institute of Informatics, Japan - Daan Leijen, Microsoft Research, USA - Shin-Cheng Mu, Academia Sinica, Taiwan - Dominic Orchard, University of Kent, UK - Peter-Michael Osera, Grinnell College, USA - Zoe Paraskevopoulou, Princeton University, USA - Alberto Pardo, Universidad de la Republica, Uruguay - Matthieu Sozeau, University of Paris Diderot, Paris 7, France - Niki Vazou, University of Maryland, USA (co-chair) *Submission details* Submissions should fall into one of two categories: - Regular research papers (12 pages) - Extended abstracts (2 pages) The bibliography will not be counted against the page limits for either category. Regular research papers are expected to present novel and interesting research results, and will be included in the formal proceedings. Extended abstracts should report work in progress that the authors would like to present at the workshop. Extended abstracts will be distributed to workshop attendees but will not be published in the formal proceedings. We welcome submissions from PC members (with the exception of the two co-chairs), but these submissions will be held to a higher standard. Submission is handled through HotCRP: https://tyde18.hotcrp.com/ All submissions should be in portable document format (PDF) and formatted using the ACM SIGPLAN style guidelines: http://www.sigplan.org/Resources/Author/ Note that the ACM SIGPLAN style guidelines have changed from previous years! In particular, submissions should use the new ‘acmart’ format and the two-column ‘sigplan’ subformat (not to be confused with the one-column ‘acmlarge’ subformat!). Extended abstracts must be submitted with the label ‘Extended abstract’ clearly in the title.

1 0

1st CfP: IFL 2018 (30th Symposium on Implementation and Application of Functional Languages)
by Jurriaan Hage 13 Mar '18

13 Mar '18

Hello, Please, find below the first call for papers for IFL 2018. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- ================================================================================ IFL 2018 30th Symposium on Implementation and Application of Functional Languages University of Massachusetts Lowell, MA, USA September 5th-7th, 2018 http://iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2018 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Submissions and peer-review Differently from previous editions of IFL, IFL 2018 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2018. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: May 25, 2018 Submission of draft papers: July 17, 2018 Regular and draft papers notification: July 20, 2018 Deadline for early registration: August 8, 2018 Submission of pre-proceedings version: August 29, 2018 IFL Symposium: September 5-7, 2018 Submission of papers for post-proceedings: November 7, 2018 Notification of acceptance: December 22, 2018 Camera-ready version: February 10, 2019 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2018 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jay McCarthy & Matteo Cimini, University of Massachusetts Lowell, USA Program Committee: * Arthur Chargu√©raud, Inria, FR * Ben Delaware, Purdue University, USA * Christos Dimoulas, Northwestern University, USA * David Darais, University of Vermont, USA * Dominic Orchard, University of Kent, UK * Ekaterina Komendantskaya, Heriot-Watt University, UK * Garrett Morris, University of Kansas, USA * Heather Miller, EPFL & Northeastern University, CH & USA * Jeremy Yallop, University of Cambridge, UK * Keiko Nakata, SAP Innovation Center Potsdam, DE * Laura Castro, University of A Coru√±a, ESP * Magnus Myreen, Chalmers University of Technology, SWE * Natalia Chechina, Bournemouth University, UK * Peter Achten, Radboud Universiteit Nijmegen, NL * Peter-Michael Osera, Grinnell College, USA * Richard Eisenberg, Bryn Mawr College, USA * Trevor McDonell, University of New South Wales, AUS * Yukiyoshi Kameyama, University of Tsukuba, JAP ### Venue The 30th IFL will take place at the UMass Lowell Inn & Conference Center in Lowell (MA), in association with the University of Massachusetts Lowell. The City of Lowell is located at the heart of the Merrimack Valley just 30 miles northwest of Boston. Lowell can be easily reached by train or taxi. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2018 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences.

1 0

Serialising data between Haskell and C#
by Clinton Mead 12 Mar '18

12 Mar '18

Hi All I want to integrate Haskell into an existing C# project, initially by creating one C# class that basically does all it's "work" in Haskell (and just provides a C# interface). There will be a few types passed in and out of this Haskell module from/to C#. On the C# side, there are classes with members, who's types are probably going to be either Strings, Ints, or lists of Strings/Ints, or lists of other objects. I'd like to have the same types on the Haskell side. It would be nice if I could just magically pass one of these C# types to Haskell and on the Haskell side it will appear as a Haskell type I assume what I'll have to do is serialise the type on the C# side and deserialise on the Haskell side. C# allows one to serialise any data type to XML. Haskell has plenty of serialisation libraries as well. However, the problem I presume is that if I just serialise to XML on the C# side, and deserialise from XML on the Haskell side, if my types are just slightly different, or even if the exact serialisers/deserialises represent their data in different ways, it isn't going to work. It seems like passing complex data to/from Haskell may be a common problem other people experience, so I'm looking for any suggestions on a clean way of doing this.

5 4

Midlands Graduate School 2018 - final call for participation
by Graham Hutton 12 Mar '18

12 Mar '18

Dear all, There are just a few days left now to register for this years Midlands Graduate School (MGS) in Nottingham: eight fantastic courses on dependently typed programming, categories, lambda calculus, semantics, and more. Registration closes on Friday 16th March. Please share! http://tinyurl.com/MGS18NOTT Best wishes, Graham Hutton and Henrik Nilsson ========================================================== Midlands Graduate School 2018 9-13 April 2018, Nottingham, UK http://tinyurl.com/MGS18NOTT BACKGROUND: The Midlands Graduate School (MGS) in the Foundations of Computing Science provides an intensive course of lectures on the mathematical foundations of computing. The MGS has been running since 1999, and is aimed at PhD students in their first or second year of study, but the school is open to everyone, and has increasingly seen participation from industry. We welcome participants from all over the world! COURSES: Eight courses will be given. Participants usually take all the introductory courses and choose additional options from the advanced courses depending on their interests. Invited course - Type-Driven Development with Idris, Edwin Brady Introductory courses - Lambda Calculus, Venanzio Capretta - Category Theory, Roy Crole - Domain Theory and Denotational Semantics, Achim Jung Advanced courses - Univalent Foundations, Benedikt Ahrens - Coalgebra, Alexander Kurz - Separation Logic, Georg Struth - Machine Learning, Michel Valstar REGISTRATION: Registration is £550 for student, academic and independent participants, and £850 for industry participants. The fee includes 5 nights single en-suite accommodation (Sun-Thu), lunch and coffee breaks, and the conference dinner. The registration deadline is ** Friday 16th March **. Spaces are limited, so please register early to secure your place. SPONSORSHIP: We offer a range of sponsorship opportunities for industry (bronze, silver, gold and platinum), each with specific benefits. Please see the website for further details. ========================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Midlands Graduate School 2018 - final call for participation
by Graham Hutton 12 Mar '18

12 Mar '18

Dear all, There are just a few days left now to register for this years Midlands Graduate School (MGS) in Nottingham: eight fantastic courses on dependently typed programming, categories, lambda calculus, semantics, and more. Registration closes on Friday 16th March. Please share! http://tinyurl.com/MGS18NOTT Best wishes, Graham Hutton and Henrik Nilsson ========================================================== Midlands Graduate School 2018 9-13 April 2018, Nottingham, UK http://tinyurl.com/MGS18NOTT BACKGROUND: The Midlands Graduate School (MGS) in the Foundations of Computing Science provides an intensive course of lectures on the mathematical foundations of computing. The MGS has been running since 1999, and is aimed at PhD students in their first or second year of study, but the school is open to everyone, and has increasingly seen participation from industry. We welcome participants from all over the world! COURSES: Eight courses will be given. Participants usually take all the introductory courses and choose additional options from the advanced courses depending on their interests. Invited course - Type-Driven Development with Idris, Edwin Brady Introductory courses - Lambda Calculus, Venanzio Capretta - Category Theory, Roy Crole - Domain Theory and Denotational Semantics, Achim Jung Advanced courses - Univalent Foundations, Benedikt Ahrens - Coalgebra, Alexander Kurz - Separation Logic, Georg Struth - Machine Learning, Michel Valstar REGISTRATION: Registration is £550 for student, academic and independent participants, and £850 for industry participants. The fee includes 5 nights single en-suite accommodation (Sun-Thu), lunch and coffee breaks, and the conference dinner. The registration deadline is ** Friday 16th March **. Spaces are limited, so please register early to secure your place. SPONSORSHIP: We offer a range of sponsorship opportunities for industry (bronze, silver, gold and platinum), each with specific benefits. Please see the website for further details. ========================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

A small milestone
by Simon Peyton Jones 11 Mar '18

11 Mar '18

Cherished friends Today is my sixtieth birthday. It is just over forty years since Phil and I called in at Yale on my way to FPCA, and floated the idea of Haskell with Paul Hudak<https://www.microsoft.com/en-us/research/publication/a-history-of-haskell-b…>. (It wasn't called Haskell then, of course.) Rather a lot of water has flowed under the bridge since then. GHC's bug tracker is up to 14,683 tickets; I have read every one of them. But the best thing is Haskell's rich community of smart, motivated, passionate, and friendly colleagues. There was a time when I knew every Haskell programmer on the planet, but we are far, far beyond that point. Now it's beyond me even to keep up with the huge wave of elegant and creative ideas, tools, libraries, and blog posts that you generate. (Kudos to Taylor - and doubtless other colleagues -- for the Haskell Weekly News<https://haskellweekly.news/>, which I love.) But despite its size, it's a community that is still characterised by a love of elegance, and a desire to distil the essence of an idea and encapsulate it in an abstraction, all tempered with respect and tolerance. We don't always live up to these ideals, but by and large we do. Thank you all. Onward and upward! Simon PS: as birthday recreation I'm working on https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts

6 6

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 09 Mar '18

09 Mar '18

Vassil Ognyanov Keremidchiev <varosi(a)gmail.com> writes: > I saw there is ARM Aarch64 build, which is pretty cool! But will there be a > ARMv7 (32bit build) as well? > I do hope so. There have been a number of false-starts but hopefully the build that is currently running will finish. Unfortunately getting a working ARMv7 build is rather tricky due to a number of linker bugs that bite under various circumstances. Cheers, - Ben

1 0

Dropping containers support for old GHC versions
by David Feuer 09 Mar '18

09 Mar '18

It's that time again. I'd very much like to drop containers support for GHC version 7.0 (so I can increase the lower bound on array to 0.4 for Safe Haskell-related reasons). I'd also prefer to drop support for GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not to. What do you all think? David

6 9

Re: [Haskell-cafe] Dropping containers support for old GHC versions
by David Feuer 09 Mar '18

09 Mar '18

On Mar 9, 2018 10:55 AM, "Daniel Cartwright" <chessai1996(a)gmail.com> wrote: On a related note, I find it strange when looking through source code for 'containers'/other Haskell libraries and still see notes about supporting non-GHC Haskell compilers (e.g. Hugs) I believe we've stripped all references to Hugs and nhc98 from containers. If you find any, let us know. I'd be interested in adding support for Frege, but the way it deals with numeric literals could be problematic.

1 0

Re: [Haskell-cafe] Dropping containers support for old GHC versions
by Henning Thielemann 09 Mar '18

09 Mar '18

On Fri, 9 Mar 2018, Daniel Cartwright wrote: > I am +1 on this. > GHC 7.0 is 8 years old > GHC 7.2 is 7 years old > GHC 7.4 is 6 years old > > On a related note, I find it strange when looking through source code for 'containers'/other Haskell libraries > and still see notes about supporting non-GHC Haskell compilers (e.g. Hugs) Recently we got to install Hugs on a Lego machine - installation required several minutes. I would not try to install GHC there.

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 09 Mar '18

09 Mar '18

Niklas Larsson <metaniklas(a)gmail.com> writes: > Hi! > > It says on the download page that the Windows versions is “excluding > the Windows 10 Creator’s Update”. I’m assuming that is a copy-paste > error from the release that fixed the Windows 10 CU bug. > Oh dear, yes. Thank you for noticing this. Cheers, - Ben

1 0

do-notation for building monoid values
by Olaf Klinke 09 Mar '18

09 Mar '18

Dear cafe, prompted by a discussion with the author of blaze-markup [1] I realized a pattern and would like to know whether other haskellers have exploited this/find this useful: For every monoid m, the types Writer m () and m are isomorphic as types via tell and execWriter. Moreover, Writer m is a monad if and only if m is a monoid. For every monad t, the type t () is a monoid with mempty = return () mappend = (>>). In the particular case of Writer m () and m, the isomorphism of Haskell types is in fact an isomorphism of monoids, that is, the functions tell and execWriter preserve the monoid operations. This enables us to use do-notation in building complicated values of any monoid type, e.g. Text or any other syntax. Instead of writing complicatedValue = component1 <> component2 <> modifier (component3 <> component4) one can write complicatedValue = execWriter $ do component1 component2 modifier $ do component3 component4 Should such an idiom be encouraged/discouraged? How do you handle the construction of monoid values (especially text-like) with interspersed function applications (e.g. show, prettyprint)? Regards, Olaf [1] https://github.com/jaspervdj/blaze-markup/issues/36

5 4

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 08 Mar '18

08 Mar '18

Apostolos Syropoulos via Glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> writes: > Hello, > > I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and > compilation never starts because: > Can you try applying the attached patch? Cheers, - Ben

1 0

Final Call for Papers: PACMPL issue ICFP 2018
by Lindsey Kuper 08 Mar '18

08 Mar '18

PACMPL Volume 2, Issue ICFP 2018 Call for Papers accepted papers to be invited for presentation at The 23rd ACM SIGPLAN International Conference on Functional Programming St. Louis, Missouri, USA http://icfp18.sigplan.org/ ### Important dates Submissions due: 16 March 2018 (Friday) Anywhere on Earth https://icfp18.hotcrp.com Author response: 2 May (Wednesday) - 4 May (Friday) 14:00 UTC Notification: 18 May (Friday) Final copy due: 22 June (Friday) Conference: 24 September (Monday) - 26 September (Wednesday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL <https://pacmpl.acm.org/>) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicized Calls for Papers, like this one. ### Scope [PACMPL](https://pacmpl.acm.org/) issue ICFP 2018 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * *Language Design*: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. * *Implementation*: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * *Software-Development Techniques*: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. * *Foundations*: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. * *Analysis and Transformation*: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. * *Applications*: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. * *Education*: teaching introductory programming; parallel programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2018 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such at the time of submission and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is Friday, March 16, 2018, Anywhere on Earth (<https://en.wikipedia.org/wiki/Anywhere_on_Earth>). This deadline will be strictly enforced. **Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from <https://www.acm.org/publications/authors/submissions>. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from <http://sigplan.org/Resources/Author/#acmart-format>. There is a limit of 27 pages for a full paper or 14 pages for an Experience Report; in either case, the bibliography will not be counted against these limits. These page limits have been chosen to allow essentially the same amount of content with the new single-column format as was possible with the two-column format used in past ICFP conferences. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. See also PACMPL's Information and Guidelines for Authors at <https://pacmpl.acm.org/authors.cfm>. **Submission**: Submissions will be accepted at <https://icfp18.hotcrp.com/> Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. **Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on Wednesday, May 2, 2018, to read reviews and respond to them. **Supplementary Materials**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of the paper and learned the identity of the author(s). **Authorship Policies**: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at <https://www.acm.org/publications/authors/information-for-authors>. **Republication Policies**: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at <http://www.sigplan.org/Resources/Policies/Republication>. **Resubmitted Papers**: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2018. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns. **PACMPL issue ICFP 2018 will employ a two-stage review process.** The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on May 18, 2018. Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After five weeks (June 22, 2018), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within five weeks and hence that conditionally accepted papers will in general be accepted in the second phase. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection. **PACMPL issue ICFP 2018 will employ a lightweight double-blind reviewing process.** To facilitate this, submitted papers must adhere to two rules: 1. **author names and institutions must be omitted**, and 2. **references to authors' own related work should be in the third person** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limits for final versions of papers will be increased to ensure that authors have space to respond to reviewer comments and mandatory revisions. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options: open access on payment of a fee (**recommended**, and SIGPLAN can cover the cost as described next); copyright transfer to ACM; or retaining copyright but granting ACM exclusive publication rights. Further information about ACM author rights is available from <http://authors.acm.org>. * PACMPL is a Gold Open Access journal. It will be archived in ACM’s Digital Library, but no membership or fee is required for access. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. * ACM offers authors a range of copyright options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article [Why CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open Access Scholarly Publishers Association. * We intend that the papers will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit <http://www.acm.org/publications/acm-author-izer-service> to learn how to create links for free downloads from the ACM DL. * At least one author of each accepted submissions will be expected to attend and present their paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents. * The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to *two weeks prior* to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. Further information about the motivations and expectations for Artifact Evaluation can be found at <https://icfp18.sigplan.org/track/icfp-2018-Artifacts>. ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page, and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. #### Experience Reports The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works — or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the papers and in any citations, the title of each accepted Experience Report must begin with the words "Experience Report" followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better off submitted it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Robby Findler (Northwestern University, USA) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Ryan R. Newton (Indiana University, USA) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Matthew Fluet (Rochester Institute of Technology, USA) Publicity and Web Chair: Lindsey Kuper (Intel Labs, USA) Student Research Competition Chair: Ilya Sergey (University College London, UK) Video Co-Chairs: Jose Calderon (Galois, Inc., USA) Nicolas Wu (University of Bristol, UK) Workshops Co-Chair: David Christiansen (Indiana University, USA) Christophe Scholliers (Universiteit Gent, Belgium) ### PACMPL Volume 2, Issue ICFP 2018 Principal Editor: Matthew Flatt (Univesity of Utah, USA) Review Committee: Sandrine Blazy (IRISA, University of Rennes 1, France) David Christiansen (Indiana University, USA) Martin Elsman (University of Copenhagen, Denmark) Marco Gaboardi (University at Buffalo, CUNY, USA) Sam Lindley (University of Edinburgh, UK) Heather Miller (Northweastern University, USA / EPFL, Switzerland) J. Garrett Morris (University of Kansas, USA) Henrik Nilsson (University of Nottingham, UK) François Pottier (Inria, France) Alejandro Russo (Chalmers University of Technology, Sweden) Ilya Sergey (University College London, UK) Michael Sperber (Active Group GmbH, Germany) Wouter Swierstra (Utrecht University, UK) Éric Tanter (University of Chile, Chile) Katsuhiro Ueno (Tohoku University, Japan) Niki Vazou (University of Maryland, USA) Jeremy Yallop (University of Cambridge, UK) External Review Committee: Michael D. Adams (University of Utah, USA) Amal Ahmed (Northeastern University, USA) Nada Amin (University of Cambridge, USA) Zena Ariola (University of Oregon) Lars Bergstrom (Mozilla Research) Lars Birkedal (Aarhus University, Denmark) Edwin Brady ( University of St. Andrews, UK) William Byrd (University of Alabama at Birmingham, USA) Giuseppe Castagna (CRNS / University of Paris Diderot, France) Sheng Chen (University of Louisiana at Lafayette, USA) Koen Claessen (Chalmers University ot Technology, Sweden) Ugo Dal Lago (University of Bologna, Italy / Inria, France) David Darais (University of Vermont, USA) Joshua Dunfield (Queen’s University, Canada) Richard Eisenberg (Bryn Mawr College, USA) Matthew Fluet (Rochester Institute of Technology, USA) Nate Foster (Cornell University, USA) Jurriaan Hage (Utrecht University, Netherlands) David Van Horn (University of Maryland, USA) Zhenjiang Hu (National Institute of Informatics, Japan) Suresh Jagannathan (Purdue University, USA) Simon Peyton Jones (Microsoft Research, UK) Naoki Kobayashi (University of Tokyo, Japan) Neelakantan Krishnaswami (University of Cambridge, UK) Kazutaka Matsuda (Tohoku University, Japan) Trevor McDonell (University of New South Wales, Australia) Hernan Melgratti (University of Buenos Aires, Argentina) Akimasa Morihata (University of Tokyo, Japan) Aleksandar Nanevski (IMDEA Software Institute, Spain) Kim Nguyễn (University of Paris-Sud, France) Cosmin Oancea (DIKU, University of Copenhagen, Denmark) Bruno C. d. S. Oliveira (University of Hong Kong, China) Tomas Petricek (University of Cambridge, UK) Benjamin Pierce (University of Pennsylvania, USA) Christine Rizkallah (University of Pennsylvania, USA) Tom Schrijvers (KU Leuven, Belgium) Manuel Serrano (Inria, France) Jeremy Siek (Indiana University, USA) Josef Svenningsson (Chalmers University of Technology, Sweden) Nicolas Tabareau (Inria, France) Dimitrios Vytiniotis (Microsoft Research, UK) Philip Wadler (University of Edinburgh, UK) Meng Wang (University of Kent, UK)

1 0

BayHac 2018: Call for Proposals
by Dan Burton 08 Mar '18

08 Mar '18

https://goo.gl/forms/TZbFNIZu4Q1dEh2g2 We are looking to fill out the BayHac 2018 schedule with talks and workshops. Last year we had many wonderful (and lengthy) talks, thanks! This year we are cutting down on the length of talks, as well as the overall time dedicated to them. This will leave more time for hacking. While we hope to accommodate everyone who desires to present, we are asking for proposals this year, which may be rejected if we get more than our limited schedule will allow. Propose a talk: 10 mins to present, 5 mins for questions. Talks will be recorded and uploaded to YouTube as they were last year. Propose a workshop: looser time constraints, smaller audiences. Workshops are interactive, guided lectures. Those in attendence will follow your guidance to write and run Haskell code on their own machine. Workshops will not be recorded. If we have difficulty fitting all talks and workshops into the schedule, note that workshops will be strongly preferred. Propose a set of exercises: no presentation necessary. We would like to have recommended sets of exercises for BayHac attendees to try out and discuss amongst themselves at their leisure. These can be pre-existing sets of exercises, or novel ones that you create. To make a proposal, please fill out this google form: https://goo.gl/forms/TZbFNIZu4Q1dEh2g2 Thank you for helping us make BayHac a delightful, educational event for all in attendance. -- Dan Burton

1 0

QFPL is hiring 5 functional programmers
by David Laing 08 Mar '18

08 Mar '18

Hi all, QFPL is the Queensland Functional Programming Lab (QFPL) - where I work - and we have 5 positions open in Brisbane, Australia. We're part of Data61, the Australia federal organization that does research and engineering in the data science / ICT space. Our main focus in the lab is on doing things that make it easier for software engineers to use functional programming. This involves: - creating and running courses - improving libraries, documentation and tools - writing libraries and tools to fill gaps in the ecosystem All of the things we create are open-source. You can look at the job description / apply here: https://jobs.csiro.au/job/Brisbane%2C-QLD-EOI-Functional-Programming-Softwa… As far as I know, we're not currently hiring remote workers, but relocation support is a possibility. If you have questions about the lab or the role, I'm happy to answer them. Cheers, Dave

1 0

1st call for papers: Trends in Functional Programming, 11-13 june 2018, Chalmers Campus Johanneberg, Gothenburg
by Peter Achten 07 Mar '18

07 Mar '18

----------------------------- C A L L F O R P A P E R S ----------------------------- ======== TFP 2018 =========== 19th Symposium on Trends in Functional Programming 11-13 June, 2018 Chalmers Campus Johanneberg, Gothenburg http://www.cse.chalmers.se/~myreen/tfp2018/index.html The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below at scope). Please be aware that TFP uses two distinct rounds of submissions (see below at submission details). TFP 2018 will be the main event of a pair of functional programming events. TFP 2018 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 14. == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: Leading-edge, previously unpublished research work Position Articles: On what new trends should or should not be Project Articles: Descriptions of recently started new projects Evaluation Articles: What lessons can be drawn from a finished project Overview Articles: Summarizing work with respect to a trendy subject. Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2018 program chairs, Michał Pałka and Magnus Myreen. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Paper Submissions == We use EasyChair for the refereeing process. The link to the submission page is: https://easychair.org/conferences/?conf=tfp2018 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. == Important Dates == Submission (pre-symposium review): March 26, 2018 Submission (draft, post-symposium review): April 26, 2018 Notification (pre- and post-symposium review): May 3, 2018 Registration: June 3, 2018 TFP Symposium: June 11-13, 2018 TFPIE Workshop: June 14, 2018 Student papers feedback: June 21, 2018 Submission (post-symposium review): August 14, 2018 Notification (post-symposium review): September 20, 2018 Camera-ready paper (pre- and post-symposium review): November 30, 2018 == Program Committee == Program Co-chairs Michał Pałka, Chalmers University of Technology (SE) Magnus Myreen, Chalmers University of Technology (SE) Program Committee Soichiro Hidaka, Hosei University (JP) Meng Wang, University of Bristol (UK) Sam Tobin-Hochstadt, Indiana University Bloomington (US) Tiark Rompf, Purdue University (US) Patricia Johann, Appalachian State University (US) Neil Sculthorpe, Nottingham Trent University (UK) Andres Löh, Well-Typed LLP (UK) Tarmo Uustalu, Tallinn University of Technology (EE) Cosmin E. Oancea, University of Copenhagen (DK) Mauro Jaskelioff, Universidad Nacional de Rosario (AR) Peter Achten, Radboud University (NL) Dimitrios Vytiniotis, Microsoft Research (UK) Alberto Pardo, Universidad de la República (UY) Natalia Chechina, University of Glasgow (UK) Peter Sestoft, IT University of Copenhagen (DK) Scott Owens, University of Kent (UK)

1 0

Fwd: Monad Transformers stack with variable depth
by leonidasbo . 07 Mar '18

07 Mar '18

Hello, I am a beginner with Haskell and the last few days I am troubled on how to form a stack of Monad Transformers. The following example demonstrates the use of multiple State monads without the use of Monad Transformers: data Item = Item { rCounter :: Int } increaseCounter :: State Item () increaseCounter = do val <- gets rCounter modify (\i -> i { rCounter = val + 1 }) data ItemManager = ItemManager { rItems :: [Item] } addItem :: Item -> State ItemManager () addItem item = do items <- gets rItems modify (\mgr -> mgr { rItems = items ++ [item] }) increaseCounterInItems :: State ItemManager () increaseCounterInItems = do items <- gets rItems let items' = map *(execState increaseCounter)* items modify (\mgr -> mgr { rItems = items' }) main :: IO () main = $ do let itemMgrState = do addItem $ Item 0 addItem $ Item 10 increaseCounterInItems let itemMgr = execState itemMgrState $ ItemManager [] let items = rItems itemMgr putStrLn rCounter (items !! 0) -- prints 1 putStrLn rCounter (items !! 1) -- prints 11 In the above implementation calls *execState, *inside functions of ItemManager, for updating Items. I have read about MonadTransformers and that they give you the ability to use monads inside the context of another monad. So I would like to use StateT in signatures of ItemManager's functions and avoid calling *execState, *something like this: increaseCounterInltems :: StateT ItemManager (State Item) () But I cannot find a way to implement the above function. The root cause of the difficulty seems to be that ItemManager contains multiple Items. The Monad Transformer stack contains a single State Item. So it seems to me that I am following the wrong approach. How could I use Monad Transformers in order to avoid calling *execState* for modifying Items in ItemManager? Thanks in advance, Leonidas <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#m_-5826819471182298913_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

4 3

sv library for your csv|psv|tsv
by Tony Morris 06 Mar '18

06 Mar '18

Hi everyone, The Queensland Functional Programming Lab has released the sv library for parsing, editing and calculating results based on * separated value file formats such as CSV, PSV and TSV. https://hackage.haskell.org/package/sv This first release of the library is 6 months of work by the FP lab. If you are familiar with the original argonaut[^1] library in scala or purescript, you will know of the idea of codecs for converting a syntax tree into your user-defined values. For example, taking a JSON data type to your own Person data type. Some of these ideas have been adapted to the aeson library. The sv library implements these same original ideas, with corrections to a few of the original mistakes that we made in argonaut. The sv library also retains the inverse law to parsing (write . parse = id), so you can use the library for editing CSV|PSV|TSV files. Characters such as whitespace, quotes, etc are retained in the syntax tree. If there are any questions, please feel free to contact us http://qfpl.io/contact [^1]: http://argonaut.io/

1 0

VerifyThis 2018: Call for Participation and Travel Grants
by Andrei Paskevich 06 Mar '18

06 Mar '18

******************************************************************************** VerifyThis Verification Competition 2018 CALL FOR PARTICIPATION -- TRAVEL GRANTS Competition to be held at ETAPS 2018 http://verifythis.ethz.ch ******************************************************************************** IMPORTANT DATES Grant application deadline: March 12, 2018 Competition: April 14 and 15, 2018 ABOUT VerifyThis 2018 is a program verification competition taking place as part of the European Joint Conferences on Theory and Practice of Software (ETAPS 2018) on April 14-15, 2018 in Thessaloniki, Greece. It is the 7th event in the VerifyThis competition series. The competition will offer a number of challenges presented in natural language and pseudo code. Participants have to formalize the requirements, implement a solution, and formally verify the implementation for adherence to the specification. There are no restrictions on the programming language and verification technology used. The correctness properties posed in problems will have the input-output behaviour of programs in focus. Solutions will be judged for correctness, completeness, and elegance. PARTICIPATION: Participation is open for anybody interested. Teams of up to two people are allowed. Registration for ETAPS workshops and physical presence on site is required. We particularly encourage participation of: - student teams (this includes PhD students) - non-developer teams using a tool someone else developed - several teams using the same tool TRAVEL GRANTS: The competition has funds for a limited number of travel grants. A grant covers the incurred travel and accommodation costs up to a certain limit. The expected limit is EUR 350 for those coming from Europe and EUR 600 for those coming from outside Europe. To apply for a travel grant, send an email to verifythis(a)cs.nuim.ie by March 12, 2018. The application should include: - your name - your affiliation - the verification system(s) you plan to use at the competition - the planned composition of your team - a short letter of motivation explaining your involvement with formal verification so far - if you are a student, please state the academic degree you are seeking and have your supervisor send a brief letter of support to verifythis(a)cs.nuim.ie ORGANIZERS * Marieke Huisman, University of Twente, the Netherlands * Rosemary Monahan, Maynooth University, Ireland * Peter Müller, ETH Zürich, Switzerland * Andrei Paskevich, Paris-Sud University, France * Gidon Ernst, National Institute of Informatics Tokyo, Japan CONTACT Email: verifythis(a)cs.nuim.ie Web: http://verifythis.ethz.ch

1 0

missing optimization for (++)
by Ben Franksen 05 Mar '18

05 Mar '18

I found that in base [1] we have (++) [] ys = ys (++) (x:xs) ys = x : xs ++ ys I had expected there to be a clause (++) xs [] = xs at the top, which would avoid the list traversal in this common case. Is this somehow magically taken care of by the {-# RULES "++" [~1] forall xs ys. xs ++ ys = augment (\c n -> foldr c n xs) ys #-} ? No, inlining @augment g xs = g (:) xs@ gives me (\c n -> foldr c n xs) (:) ys = foldr (:) ys xs which still traverses xs even if ys=[]. Any thoughts? [1] http://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Base.html#%2B… Cheers Ben

9 11

Haskell memory model
by Li-yao Xia 05 Mar '18

05 Mar '18

Hello café, What guarantees are there about shared memory concurrency in Haskell? In particular, I'm wondering how to correctly and efficiently synchronize mutable operations from the vector package, using stm or atomic-primops. - Are reads/writes on vectors sequentially consistent? As a concrete example, can the following program (a common test for relaxed memory models) print anything? import qualified Data.Vector.Mutable as MV import Control.Concurrent main :: IO () main = do v <- MV.replicate 2 0 t <- newEmptyMVar forkIO $ do MV.write v 0 1 x <- MV.read v 1 putMVar t x forkIO $ do MV.write v 1 1 x <- MV.read v 0 putMVar t x a <- takeMVar t b <- takeMVar t if a == 0 && b == 0 then putStrLn "Relaxed!" else return () - Do atomic operations (via stm or atomic-primops) imply some constraints between vector operations? As another concrete example, can the snippet linked below ever throw an exception? One thread writes to a vector, and another reads from it, and they communicate via stm to guess whether the read value is safe to evaluate (in one test case the first thread overwrites a defined value with undefined, and in the other case it overwrites undefined with a defined value). http://lpaste.net/362596 Regards, Li-yao

2 2

Re: [Haskell-cafe] missing optimization for (++)
by Markus Läll 04 Mar '18

04 Mar '18

Hi Viktor What I think the OP is asking for is a case where the original list would be returned immediately if the second is empty -- keeping the original spine. Since that case is missing then the list is pattern-matched and then reconstructed. Whether this actually happens after compilation is the real question. On Mar 4, 2018 21:24, "Viktor Dukhovni" <ietf-dane(a)dukhovni.org> wrote: > On Mar 4, 2018, at 4:32 AM, Ben Franksen <ben.franksen(a)online.de> wrote: > > I found that in base [1] we have > > (++) [] ys = ys > (++) (x:xs) ys = x : xs ++ ys > > I had expected there to be a clause > > (++) xs [] = xs > > at the top, which would avoid the list traversal in this common case. > > [...] > > which still traverses xs even if ys=[]. > > Any thoughts? Haskell is lazy, the traversal of x happens only when the combined list is actually traversed, and only for as many elements as requested, so the construction of the concatenated list carries little additional cost. And as pointed out, needlessly forcing the first element of y can have unintended consequences. For example: GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> let x = [1..] Prelude> let y = [1..] Prelude> let z = x ++ y Prelude> take 20 z [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20] -- Viktor. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

1 0

cabal: Couldn't parse the output of 'setup register --gen-pkg-config':NoParse
by Henk-Jan van Tuyl 03 Mar '18

03 Mar '18

L.S., I am trying to get wxHaskell compiled with GHC 8.4.0.20180224 and cabal-install 2.1.0.0; compilation fails with the message: wxcore-0.93.0.0-1L9rVktyK3zIYrrLxBiCr9 failed during the final install step. The exception was: dieVerbatim: user error (cabal: Couldn't parse the output of 'setup register --gen-pkg-config':NoParse "license" 5 ) I am using Windows 8.1. Can anybody tell me what to do about this? Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

ANN: network-2.6.3.4
by evan＠evan-borden.com 01 Mar '18

01 Mar '18

Announcing network-2.6.3.4 * Don't touch IPv6Only when running on OpenBSD [#227](https://github.com/haskell/network/pull/227) * Do not closeFd within sendFd [#271](https://github.com/haskell/network/pull/271) * Updating examples and docs. A big thanks to the network contributors. http://hackage.haskell.org/package/network-2.6.3.4

1 0

Software engineer job situated in a PL research group
by Ryan Newton 28 Feb '18

28 Feb '18

Hi all, This posting is for a potentially long term position with the department. In the short term the work will be largely about sandboxing, containerization, and other low level systems stuff, but *all* the high-level software in the group is written in Haskell: https://iujobs.peopleadmin.com/postings/44056 The OOPSLA17 paper, "Monadic Composition for Deterministic, Parallel Batch Processing <https://2017.splashcon.org/event/splash-2017-oopsla-detflow-a-monad-for-det…>", should give an idea of what this initial project is about. The engineer would be co-located with a large Programming Languages group (6 faculty and a couple dozen Ph.D. students). University benefits are good and our college town combines culture and beautiful surroundings with convenience and affordability. Best regards, -Ryan

1 0

[ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 28 Feb '18

28 Feb '18

The GHC development team is pleased to announce the first (and likely final) release candidate of GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-rc1 This release will likely be the last release before the final 8.4.1 release, which, if things go well, will be released one week from today. Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release candidate is still affected by #14705, although this will certainly be resolved before the final release is made. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

3 5

Optimization demonstration
by Dušan Kolář 28 Feb '18

28 Feb '18

Dear Café, I'm trying to do very small, but impressive example about optimizations possible during Haskell compilation. So far, I can demonstrate that the following two programs (if compiled) perform computation in the same time: 1) main = putStrLn $ show $ sum $ map (*(2::Int)) [(1::Int)..(100000000::Int)] 2) main = putStrLn $! show $! sumup 1 0 sumup :: Int -> Int -> Int sumup n total = if n<=(100000000::Int) then sumup (n+1) $! total+(2*n) else total Nevertheless, I expect a question on comparison with C: 3) #include <stdio.h> int main(void) { long sum, i; sum = 0; for (i=1; i <= 100000000L; ++i) { sum += 2*i; } printf("%ld\n",sum); return 0; } Unfortunately, in this case the C is much more faster (it prints the result immediately), at least on my machine. Is it due to a fact that C compiler does a brutal optimization leading to compile-time evaluation, while ghc is not able to do that? I'm using -O2 -dynamic --make ghc compiler flags. For gcc for C compilation just -O2, running Arch Linux. Is there any option, how to force compile time evaluation? The reason, why I think it works this way is the fact, that when running out of long type values in C a code is generated that computes the values regularly (providing misleading value as a result) taking its time. Best regards, Dušan

6 8

Re: [Haskell-cafe] Optimization demonstration
by Dušan Kolář 28 Feb '18

28 Feb '18

Many thanks all for replies, yes, that's what I assumed/wrote. C compiler does compile- time evaluation, while ghc does another transformation. And, well, yes, declaring upper bound in loop in extra file breaks the optimization for C compiler and, thus, both evaluation times for C and Haskell binaries are the same thus. Thank you once, again, Dušan P.S. If anyone can point me to resource, where examples on demonstration of Haskell optimization are, I'll be very glad. D. On úterý 27. února 2018 23:06:38 CET Richard O'Keefe wrote: > In order to optimise array indexing and to automatically vectorise > your code, high performance compilers for imperative languages > like C and Fortran analyse counted loops like you wouldn't believe. > You can find out what the C compiler does with your code by using > the -S command line option. gcc 7.2 optimised the whole loop away. > > Split your C program into two files. > One contains > long bound = 100000000L, incr = 1L; > The other is a version of your existing code with > extern long bound, incr; > ... > for (i = 1L; i <= bound; i += incr) { ... } > ... > gcc 7.2 isn't quite smart enough to optimise this away. Yet. > > The polyhedral optimisations going on are described in the > open literature and are valuable for imperative array- > crunching code. You are not likely to see them in GHC any > time soon, just as you're not likely to see deforestation > in gcc any time soon. > > On 28 February 2018 at 04:06, Dušan Kolář <kolar(a)fit.vut.cz> wrote: > > Dear Café, > > > > > > > > I'm trying to do very small, but impressive example about optimizations > > possible during Haskell compilation. So far, I can demonstrate that the > > following two programs (if compiled) perform computation in the same time: > > > > > > > > 1) > > > > > > > > main = > > > > putStrLn $ show $ sum $ map (*(2::Int)) [(1::Int)..(100000000::Int)] > > > > > > > > > > > > 2) > > > > > > > > main = > > > > putStrLn $! show $! sumup 1 0 > > > > > > > > sumup :: Int -> Int -> Int > > > > sumup n total = > > > > if n<=(100000000::Int) then sumup (n+1) $! total+(2*n) > > > > else total > > > > > > > > > > > > Nevertheless, I expect a question on comparison with C: > > > > > > > > 3) > > > > > > > > #include <stdio.h> > > > > > > > > int main(void) { > > > > long sum, i; > > > > sum = 0; > > > > for (i=1; i <= 100000000L; ++i) { > > > > sum += 2*i; > > > > } > > > > printf("%ld\n",sum); > > > > return 0; > > > > } > >

1 0

Type level variants
by Brian Hurt 27 Feb '18

27 Feb '18

I'm looking for pointers on how to do something. What I'm trying to do: I want to define a newtype wrapper for database connections with a phantom type to control whether the connection is read-only or read-write. So I have: newtype Conn a = Conn { unConn :: Connection } data ReadOnly = ReadOnly data ReadWrite = ReadWrite -- Simplifying here openConn :: MonadIO m => a -> Conn a query :: (MonadIO m, ToRow r, FromRow s) => Conn a -> Query -> r -> m [s] execute :: (MonadIO m, ToRow r) => Conn a -> Query -> r -> m Int64 But I want to be able to restrict the type a to be either ReadOnly or ReadWrite. Solutions I've come up with so far are: - Don't bother. Later function calls put enough of constraint on the types that it isn't really necessary. Or rather, ReadWrite is necessary, but ReadOnly isn't. - Define some type class that ReadWrite and ReadOnly implement, but don't export the body of the typeclass from the module, preventing other people from implementing it for other types. - Some sort of trickiness with closed type families that I haven't worked out yet. Are their alternatives I haven't considered yet? Thanks. Brian

3 3

Partial instance of a class
by Jeroen Bransen 27 Feb '18

27 Feb '18

Hi Haskell cafe, Is there any standard or guideline for making a "partial" instance of a class, by which I mean implementing some methods of a class, but not all of them? In my concrete case I've got some type X which is almost an Arrow, except that I cannot lift any function a -> b to my type (of course I can for some a and b), so I cannot give a sensible implementation for arr. I can however give sensible implementations for the other methods in the Arrow class, and I'd like to use them (and possibly derived combinators) in other places. I see three possible solutions for this situation, I think I've seen at least the first two being used in well-known packages, but I couldn't find them anymore: 1. Make a class instance, and for the methods you don't implement put an 'error' call 2. Create functions with names from the class and with types specialised to your type, so that you can use it as if the instance was there. I.e. provide a function first :: X a b -> X (a, c) (b, c), which should be imported qualified to avoid name conflicts with the real Arrow class. The drawback of this is of course the conflicting names, but also the fact that derived combinators cannot be used. 3. Create functions with different names, to also avoid name clashes, i.e. firstX :: X a b -> X (a, c) (b, c). My preference would be to pick 1., but it feels quite bad in the same time. Any suggestions? Jeroen

9 20

Haskell at Work screencasts
by Oskar Wickström 26 Feb '18

26 Feb '18

Hi fellow Haskellers! I just wanted to announce a project of mine that might be of interest. Since the beginning of this year I've been producing freely available Haskell screencasts, named "Haskell at Work". They focus on practical industry use of Haskell, and are primarily geared towards rookie and intermediate Haskellers. You'll find the videos, including show notes, here: https://haskell-at-work.com/ If you like my videos and think more people should see them, please help me spread the word! There's also a Patreon page where you or others can help out by donating: https://www.patreon.com/haskellatwork So far I've had a great time making screencasts, even if it's a lot of work. The warm feedback and many viewers is highly motivating! Best, Oskar

1 0

Re: [Haskell-cafe] runGet exits prematurely
by Quentin Liu 26 Feb '18

26 Feb '18

Thank you for the suggestion! I am still not sure about the correct way to communicate on mailing-list. But I have figured out the problem which is caused by arithmetic overflow. I was using Word8 to parse the packet length and presumed the packet length would be larger than 46. The subtraction of 47 from the Word8 packet length gave the largest number Word8 could represent, which definitely exceeds the length of the whole file. Regards, Qingbo Liu On Feb 26, 2018, 02:41 -0500, Robin Palotai <palotai.robin(a)gmail.com>, wrote: > [-list] > > FYI Given the lack of responses, I think more context would help. For example github / gist link to code, minimal case to reproduce. > > > 2018-02-23 16:59 GMT+01:00 Quentin Liu <quentin.liu.0415(a)gmail.com>: > > > Hi, > > > > > > I am using Data.Binary to decode binary files and found that the `runGet` function would throw an exception “not enough bytes” even though it has not consumed all the input. > > > > > > Specifically, in the loop I am repeatedly trying to parse the binary file until it has consumed all the input > > > > > > parsePPackets xs = do > > > empty <- isEmpty > > > if empty > > > then return xs > > > else do p <- parseB6034 > > > parsePPackets (p:xs) > > > > > > When I try to run this function with `runGet`, the exception “Data.Binary.Get.runGet at position 3293603: not enough bytes” would be thrown, while the total length of input is 5864230, a number significantly larger. The function `parseB6034` consumes no more than 250 bytes in each round. In addition, the `parsePPackets` works well when fed with a small amount of data. > > > > > > Is it the problem of my code or an error with the package binary? The ByteString fed into `runGet` is lazy ByteString, as required by `runGet` function. > > > > > > Best Regards, > > > Qingbo Liu > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > To (un)subscribe, modify options or view archives go to: > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > Only members subscribed via the mailman list are allowed to post. >

1 0

[ANN] show-combinators: a minimal pretty-printing library for Show instances
by Li-yao Xia 25 Feb '18

25 Feb '18

Hello, Sometimes it is necessary to handwrite instances for Show, Show1, Show2, or some other simple pretty-printer for ADT-like structures (because they might not be easily derived via existing means). base has a few combinators in Prelude, Text.Show, and Data.Functor.Classes. But they require explicit handling of spacing and precedence levels, which is generally error-prone and repetitive, since ADTs all look the same. This new library, show-combinators, contains just a dozen of functions to encapsulate all of those details, so the code left to write can more closely match the structure of the type to show. http://hackage.haskell.org/package/show-combinators I hope you will also find it useful. Cheers, Li-yao

1 0

Re: [Haskell-cafe] Proposal: Add Eq1 and Ord1 instances in GHC.Generics, and synchronize with Data.Functor.* types
by Zemyla 25 Feb '18

25 Feb '18

I definitely agree with adding Eq1 and Ord1 instances. We probably should have Show1 and Read1 as well, since we have normal Show and Read instances, but it should say they can't be used for deriving like Eq1 and Ord1 can. On Sun, Feb 25, 2018 at 9:10 AM, Li-yao Xia <lysxia(a)gmail.com> wrote: > Eq1 and Ord1 are two more useful classes to implement in GHC.Generics, and > would be useful to derive Eq1 and Ord1 generically. Note that we can > currently use transformers-compat to derive these. > > Moreover, most of the GHC.Generics types are equivalent to types in the > Data.Functor.* modules. Would it be a good idea for them to have the same > instances? Concretely, the current differences are: > > - GHC.Generics is missing Eq1, Ord1, Show1, Read1 instances > - Data.Functor.* is missing Semigroup and Monoid instances (that my previous > proposal would add to GHC.Generics) > > Li-yao > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

Munich Haskell Meeting, 2018-02-27 @ 19:30
by Christian Neukirchen 25 Feb '18

25 Feb '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, Feburary 27, this time at Schiller Bräu (Schillerstr. 23) at 19h30. 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-feb-2018/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

How to control emitting other-modules with hpack
by 姓名 25 Feb '18

25 Feb '18

Hi there, I don't want to refer some (test) files defined at other-modules section but hpack emits that automatically. How can I control that emitting from package.yaml?

1 1

HsOpenSSL doesn't build
by fr33domlover 25 Feb '18

25 Feb '18

Hello Haskellers, For a long time I did my Haskell coding on a laptop running Trisquel 7 GNU/Linux, 64-bit. I had stack installed from FPComplete's debian repo, and GHC 7.10.3 installed from hvr's PPA. I was working, among other things, on a program that I built last time with LTS 6.5 and everything was okay. Then I moved to a new laptop, now I run Devuan Jessie (which is basically the same as Debian 8 Jessie), 64-bit, and I have stack installed using the script provided by the stack website, and GHC installed using `stack setup`. I'm trying to build the very same program, and I get this: Configuring HsOpenSSL-0.11.1.1... Cabal-simple_mPHDZzAJ_2.0.1.1_ghc-7.10.3: Missing dependencies on foreign libraries: * Missing C libraries: crypto, ssl This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. I thought maybe my OpenSSL version is too old. That's a bit weird because it seems to be more recent than the Trisquel one (well, basically same version, just some micro version being a bit higher), but still, I decided to try a few things: - I installed OpenSSL 1.1 using Guix and used the flags mentioned above to point to Guix's include and dir paths - I downloaded OpenSSL 1.1 release tarball, built from source, installed, pointed stack to that location - In those extra dirs I listed all the system ones like /lib and /usr/lib just in case - I updated stack to the latest release, and did stack setup --upgrade-cabal and installed alex and happy because stack complained no package was providing them - I deleted .stack-work and ~/.stack and did a totally clean build But nothing works, I'm still getting this error. On the older laptop everything works. How do I go about solving this? I don't know what else to try or how to make `stack build` look in the paths I provide and see the OpenSSL library there and use it. Thanks in advance for any clues!!! -- fr33

2 2

No instance - but it could just put one in the context
by Tom Ellis 23 Feb '18

23 Feb '18

I'm puzzled by GHC's behaviour in the following program. 'baz = bar . foo' does not work because there is "no instance for ...". But if I manually assume those instances in the context all is fine. Why can GHC not infer that context? Is there any extension or clever trick I can use to get this to infer like I want? Thanks, Tom {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} class Foo a b class Bar a b type family Quux a foo :: ( Foo a b , b ~ Quux a ) => a -> Quux a foo = undefined bar :: Bar a b => a -> b bar = undefined -- Doesn't work -- No instance for (Bar (Quux a0) c0) arising from a use of ‘bar’ -- No instance for (Foo a0 (Quux a0)) arising from a use of ‘foo’ --baz = bar . foo baz' :: ( Foo a (Quux a) , Bar (Quux a) b ) => a -> b baz' = bar . foo

2 4

runGet exits prematurely
by Quentin Liu 23 Feb '18

23 Feb '18

Hi, I am using Data.Binary to decode binary files and found that the `runGet` function would throw an exception “not enough bytes” even though it has not consumed all the input. Specifically, in the loop I am repeatedly trying to parse the binary file until it has consumed all the input parsePPackets xs = do empty <- isEmpty if empty then return xs else do p <- parseB6034 parsePPackets (p:xs) When I try to run this function with `runGet`, the exception “Data.Binary.Get.runGet at position 3293603: not enough bytes” would be thrown, while the total length of input is 5864230, a number significantly larger. The function `parseB6034` consumes no more than 250 bytes in each round. In addition, the `parsePPackets` works well when fed with a small amount of data. Is it the problem of my code or an error with the package binary? The ByteString fed into `runGet` is lazy ByteString, as required by `runGet` function. Best Regards, Qingbo Liu

1 0

Occurs check: cannot construct the infinite type - but it doesn't need to
by Tom Ellis 23 Feb '18

23 Feb '18

I have run into a similar problem to my last question which is not resolved with NoMonomorphismRestriction. 'foo2' has a partial type signature and I get an occurs check. 'foo3' is exactly the same except it has no signature, and it works! Why can't 'foo2' be inferred like 'foo3'? {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE NoMonomorphismRestriction #-} type family Quux a type family Corge a foo :: ( b ~ Quux a , a ~ Corge b ) => a -> b foo = undefined -- Occurs check: cannot construct the infinite type: -- t0 ~ Corge (Quux t0) -- arising from a use of ‘foo’ -- The type variable ‘t0’ is ambiguous -- foo2 :: _ foo2 = foo foo3 = foo

1 0

Re: [Haskell-cafe] [Haskell] ANN: Hackage Account Registration Changes
by Niklas Hambüchen 23 Feb '18

23 Feb '18

On 23/02/2018 00.27, Matthias Kilian wrote: > Does it > maen that one can't trust *any* package on hackage.haskell.org at > least a little bit (based on trust between acknowledging persons > and reputation) without reviewing the package's source code? Yes, in fact you cannot trust any random code you download from the Internet, Hackage is no exception. Anybody could register and upload a package that runs some `runIO` TemplateHaskell which deletes your entire home directory upon compilation, no matter if they are verified as a human or not. Other programming languages' ecosystems don't solve this problems either; if we want it solved, we should layer a trusted curated package repository on top where all code is reviewed by a set of trusted experts.

1 0

ThEdu'18: Call for Extended Abstracts & Demonstrations
by Achim D. Brucker 23 Feb '18

23 Feb '18

(Apologies for duplicates) Call for Extended Abstracts & Demonstrations ************************************************************************** ThEdu'18 Theorem proving components for Educational software 18 July 2018 http://www.uc.pt/en/congressos/thedu/thedu18 ************************************************************************** at FLoC 2018 Federated Logic Conference 2018 6-19 July 2018 Oxford, UK http://www.floc2018.org/ ************************************************************************** THedu'18 Scope: Computer Theorem Proving is becoming a paradigm as well as a technological base for a new generation of educational software in science, technology, engineering and mathematics. The workshop brings together experts in automated deduction with experts in education in order to further clarify the shape of the new software generation and to discuss existing systems. Invited Talk Julien Narboux, University of Strasbourg, France Important Dates * Extended Abstracts: 15th April 2018 * Author Notification: 15th May 2018 * Workshop Day: 18 July 2018 Topics of interest include: * methods of automated deduction applied to checking students' input; * methods of automated deduction applied to prove post-conditions for particular problem solutions; * combinations of deduction and computation enabling systems to propose next steps; * automated provers specific for dynamic geometry systems; * proof and proving in mathematics education. Submission We welcome submission of extended abstracts and demonstration proposals presenting original unpublished work which is not been submitted for publication elsewhere. All accepted extended abstracts and demonstrations will be presented at the workshop. The extended abstracts will be made available online. Extended abstracts and demonstration proposals should be submitted via easychair, https://easychair.org/conferences/?conf=thedu18 formatted according to http://www.easychair.org/publications/easychair.zip Extended abstracts and demonstration proposals should be approximately 5 pages in length and are to be submitted in PDF format. At least one author of each accepted extended abstract/demonstration proposal is expected to attend THedu'18 and presents his/her extended abstract/demonstration. Program Committee Francisco Botana, University of Vigo at Pontevedra, Spain Roman Hašek, University of South Bohemia, Czech Republic Filip Maric, University of Belgrade, Serbia Walther Neuper, Graz University of Technology, Austria (co-chair) Pavel Pech, University of South Bohemia, Czech Republic Pedro Quaresma, University of Coimbra, Portugal (co-chair) Vanda Santos, CISUC, Portugal Wolfgang Schreiner, Johannes Kepler University, Austria Burkhart Wolff, University Paris-Sud, France Proceedings The extended abstracts and system descriptions will be available in ThEdu'18 Web-page. After presentation at the conference, selected authors will be invited to submit a substantially revised version, extended to 14--20 pages, for publication by the Electronic Proceedings in Theoretical Computer Science (EPTCS). -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Re: [Haskell-cafe] [Haskell] ANN: Hackage Account Registration Changes
by Gershom B 23 Feb '18

23 Feb '18

(Replying just on -cafe. The other cc's shouldn't be included in the follow-on discussion to this announcement). A PR to augment links with nofollow tags would be welcome. Note that for completeness this would have to be done in the markdown engine, the package-description rendering engine, _and_ the haddock generation, which are three distinct codepaths. That said, I think that does not suffice, as I do not think the intent of the spam is _just_ to perform search engine optimization. And further, I have seen other cases as well where people are undeterred by SEO-prevention measures. For example, we require manual approval of wiki.haskell.org accounts despite the addition of nofollow tags, as those did not deter spammers in that case. The current policy is not a "direction" we are taking -- it is an interim measure until a better fix can be put in place. There is some discussion of what a "better fix" might look like on an issue on hackage-server: https://github.com/haskell/hackage-server/issues/685 -g On Thu, Feb 22, 2018 at 7:26 PM, Geoffrey Huntley <ghuntley(a)ghuntley.com> wrote: > I feel that this is the wrong direction to take and will add more burden on > people that we shouldn't be adding additional burden to. It's also the wrong > "optics". > > I just had a quick squizz at Hackage with a simple PR you'll be able to > remove the incentives for this behaviour. > > Add "nofollow" to any links supplied by the user or that are rendered as > part of parsing user input. > > https://support.google.com/webmasters/answer/96569?hl=en > > The .NET ecosystem recently went through these same notions for the same > reasons - here's the PR > > https://github.com/NuGet/NuGetGallery/pull/4841/files > > On Fri., 23 Feb. 2018, 10:38 am Matthias Kilian, <kili(a)outback.escape.de> > wrote: >> >> Hi, >> >> On Thu, Feb 22, 2018 at 05:54:33PM -0500, Gershom B wrote: >> > In the meantime, as a short term measure, we have changed new account >> > registration policies on hackage. >> > >> > Users can still register as before, but new users do _not_ have upload >> > rights until they explicitly request them and are granted them by a >> > human being. >> > >> > (This is actually how we had configured hackage to work on initial >> > deployment -- we loosened things up for some years as the extra step >> > seemed unnecessary). >> >> Does this mean that before the todays change, anyone (or anything) >> could register and upload packages without any review and without >> any acknowledgement for trustfulness by another person? Does it >> maen that one can't trust *any* package on hackage.haskell.org at >> least a little bit (based on trust between acknowledging persons >> and reputation) without reviewing the package's source code? >> >> Ciao, >> Kili >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

1 0

ANN: Hackage Account Registration Changes
by Gershom B 22 Feb '18

22 Feb '18

As some people have seen, a spammer has started to create accounts on hackage to upload fake packages, in order to use their package-descriptions for linkspam. We'll be working to clean-up the package-index from this spam, and the accounts have been disabled. Further, we'll need to decide on some long-term changes going forward to make this sort of abuse more difficult. In the meantime, as a short term measure, we have changed new account registration policies on hackage. Users can still register as before, but new users do _not_ have upload rights until they explicitly request them and are granted them by a human being. (This is actually how we had configured hackage to work on initial deployment -- we loosened things up for some years as the extra step seemed unnecessary). Apologies for the inconvenience, but this seemed the most direct way to stop the current influx of spam. Users with existing hackage accounts should encounter no differences in behavior. Best, Gershom

1 0

Re: [Haskell-cafe] Pointer equality for nullary constructors
by David Feuer 22 Feb '18

22 Feb '18

Double-barreled continuations don't seem to work well when you want to abort construction of a recursive structure. Think about Data.HashMap.Strict.insert. We don't really want to have to walk all the way back up to the top if we discover that the value pointer we're inserting is the same as the I've already in the map. On Feb 22, 2018 2:55 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> wrote: David: i'm inclined to agree with Doug here. Phrased differently: what is the example change in overheads in micro or milliseconds? what is an example tiny program where those overheads are a significant part of program overhead? why woulnd't they use something like https://www.microsoft. com/en-us/research/wp-content/uploads/2007/10/compilingwithcontinuationscont inued.pdf aka the so called "double barrelled cps" transform? On Wed, Feb 21, 2018 at 11:21 PM, David Feuer <david.feuer(a)gmail.com> wrote: > Because sometimes the sanctioned way is inefficient. throwIO always > wraps its exception argument in a SomeException constructor before > calling raiseIO# on the result. That extra baggage is likely enough to > make the implementation I'm considering too slow to bother with, so I > care right now in 2018. I'd very much prefer to get an > officially-approved way to do what I want, but barring that I'll take > one that works. > > On Wed, Feb 21, 2018 at 9:33 AM, Doug McIlroy <doug(a)cs.dartmouth.edu> > wrote: > > > >> > Can I use reallyUnsafePtrEquality# reliably to identify whether a > value is > >> a nullary constructor of a particular type? > > > > Can this "optimization" possibly save enough time to justify > > nonstandard trickery? > > This kind of obscure brittle coding may have been OK 50 years > > ago. But why do it now? > > > > Doug > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. >

1 1

Pointer equality for nullary constructors
by David Feuer 22 Feb '18

22 Feb '18

Can I use reallyUnsafePtrEquality# reliably to identify whether a value is a nullary constructor of a particular type? For example, if I have data Foo = Foo Can I write isFoo :: a -> Bool isFoo !a = isTrue# (reallyUnsafePtrEquality# a Foo) instead of isFoo :: forall a. Typeable a => a -> Bool isFoo a | Just Refl <- eqTypeRep (typeRep @a) (typeRep @Foo) , Foo <- a = True | otherwise = False The reason I'm asking is because this would let me (potentially) raiseIO# a nullary constructor and then catch# it and see if it was what I was looking for rather than having to open a SomeException to get to an Exception dictionary, open that to get a TypeRep, and then peer inside that to check a Fingerprint. That is, I'd get lighter-weight exceptions that only carry the information I actually need. Thanks, David

4 6

Re: [Haskell-cafe] Pointer equality for nullary constructors
by Doug McIlroy 22 Feb '18

22 Feb '18

> > Can I use reallyUnsafePtrEquality# reliably to identify whether a value is > a nullary constructor of a particular type? Can this "optimization" possibly save enough time to justify nonstandard trickery? This kind of obscure brittle coding may have been OK 50 years ago. But why do it now? Doug

5 5