- Haskell-Cafe - Haskell.org

[TFP'19] second call for papers: Trends in Functional Programming 2019, 12-14 June 2019, Vancouver, BC, CA
by Peter Achten 15 Mar '19

15 Mar '19

-------------------------------- 2 N D C A L L F O R P A P E R S -------------------------------- ====== TFP 2019 ====== 20th Symposium on Trends in Functional Programming 12-14 June, 2019 Vancouver, BC, CA https://www.tfp2019.org/index.html == Important Dates == Submission Deadline for pre-symposium formal review Thursday, March 28, 2019 Sumbission Deadline for Draft Papers Thursday, May 9, 2019 Notification for pre-symposium submissions Thursday, May 2, 2019 Notification for Draft Papers Tuesday, May 14, 1029 TFPIE Tuesday, June 11, 2019 Symposium Wednesday, June 12, 2019 – Friday, June 14, 2019 Notification of Student Paper Feedback Friday June 21, 2019 Submission Deadline for revised Draft Papers (post-symposium formal review) Thursday, August 1, 2019 Notification for post-symposium submissions Thursday, October 24, 2019 Camera Ready Deadline (both pre- and post-symposium) Friday, November 29, 2019 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 2019 will be the main event of a pair of functional programming events. TFP 2019 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 11. == 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 2019 program chairs, William J. Bowman and Ron Garcia. == 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. == Instructions to Author == Papers must be submitted at: https://easychair.org/conferences/?conf=tfp2019 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 == Papers submitted for post-symposium 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 received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == There are two types of submission, each of which can be submitted either for pre-symposium or post-symposium review: Extended abstracts. Extended abstracts are 4 to 10 pages in length. Full papers. Full papers are up to 20 pages in length. Each submission also belongs to a category: research position project evaluation overview paper Each submission should clearly indicate to which category it belongs. Additionally, a draft paper submission—of either type (extended abstract or full paper) and any category—can be considered a student paper. A student paper is one for which primary authors are research students and the majority of the work described was carried out by the students. The submission should indicate that it is a student paper. Student papers will receive additional feedback from the PC shortly after the symposium has taken place and before the post-symposium submission deadline. Feedback is only provided for accepted student papers, i.e., papers submitted for presentation and post-symposium formal review that are accepted for presentation. If a student paper is rejected for presentation, then it receives no further feedback and cannot be submitted for post-symposium review. == 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 (http://www.springer.com/lncs) == Program Committee == Program Co-chairs William J. Bowman University of British Columbia Ronald Garcia University of British Columbia Matteo Cimini University of Massachusetts Lowell Ryan Culpepper Czech Technical Institute Joshua Dunfield Queen's University Sam Lindley University of Edinburgh Assia Mahboubi INRIA Nantes Christine Rizkallah University of New South Wales Satnam Singh Google AI Marco T. Morazán Seton Hall University John Hughes Chalmers University and Quviq Nicolas Wu University of Bristol Tom Schrijvers KU Leuven Scott Smith Johns Hopkins University Stephanie Balzer Carnegie Mellon University Viktória Zsók Eötvös Loránd University

1 0

Annoying problem when pattern matching negative integer literals and wildcards
by Vanessa McHale 15 Mar '19

15 Mar '19

I have the following program: module Bug ( encryptionResult ) where data EncryptionResult = HasEncryption | EncryptionUnknown encryptionResult :: Int -> EncryptionResult encryptionResult 1 = HasEncryption encryptionResult -1 = EncryptionUnknown encryptionResult _ = error "Internal error." When I try to compile it with GHC I get [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:1: error: Multiple declarations of ‘encryptionResult’ Declared at: Bug.hs:7:1 Bug.hs:9:1 | 9 | encryptionResult _ = error "Internal error." | ^^^^^^^^^^^^^^^^ I can replicate this in Hugs, viz. ERROR "Bug.hs":7 - "encryptionResult" multiply defined However, everything compiles fine when I write module Bug ( encryptionResult ) where data EncryptionResult = HasEncryption | EncryptionUnknown encryptionResult :: Int -> EncryptionResult encryptionResult 1 = HasEncryption encryptionResult -1 = EncryptionUnknown or module Bug ( encryptionResult ) where data EncryptionResult = HasEncryption | EncryptionUnknown encryptionResult :: Int -> EncryptionResult encryptionResult 1 = HasEncryption encryptionResult 0 = EncryptionUnknown encryptionResult _ = error "Internal error." Am I doing something obviously screwy? This seems like a pretty annoying feature on the language (to the point where I assumed it was a GHC bug until I got the same behavior with Hugs) and I can't figure out why it exists. Cheers, Vanessa McHale

3 3

How to use alex with param -g in cabal
by Kees Bleijenberg 14 Mar '19

14 Mar '19

Hi all, Alex is in the build-tools part of the cabal file. The docs of Alex says that invoking Alex with -g makes the resulting lexer significantly faster and smaller. How can I pass the -g parameter in the cabal file? Kees --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus

2 1

ANN: Radicle
by Julian Arni 13 Mar '19

13 Mar '19

Today we're releasing the alpha version of Radicle. Radicle is a p2p code collaboration platform (think Github replacement). Issues, patches (like PRs) and optionally code are distributed via IPFS, without a centralized server, and with tooling that's meant to work directly from your terminal. There's a lot more info on the webpage [0]. Radicle is written in Haskell (minus the parts that are written in the Radicle language itself, though the language is implemented in Haskell), and open-source, which is why I thought to post here. [0] www.radicle.xyz

2 1

Apply Haskell at scale in a music start-up
by Jeroen Bransen 12 Mar '19

12 Mar '19

* Dear Haskellers, Chordify is hiring! Chordify is a young and fast growing music e-learning platform that helps musicians to play their favorite music. We automatically analyse the chords of a piece of music and display them in an intuitive player. Try it yourself at: https://chordify.net/or download one of our apps https://chordify.net/app The cool thing is: our backend serving our apps and website has been written mostly in Haskell. With over 8 million users per month we apply functional programming at scale. We hope to broaden our team with a functional programmer. We are looking for people who are pro-active, independent, and creative to improve Chordify. You’d have the opportunity to be productive with advanced type-system features and powerful GHC extensions. Our back-end is powered by libraries like Servant, Persistent and Esqueleto and we distribute computation using Cloud Haskell. If you are interested in working at Chordify, please have a look at: https://jobs.chordify.net/ All the best, Jeroen Bransen *

2 2

[OT] thoughts about OO vs. functional "philosophy"
by Dennis Raddle 12 Mar '19

12 Mar '19

I have a thought about OO vs. functional programming . I'm moderately experienced with functional languages such as Haskell and Purescript and have used OO for many years at work (Python, C++). I'm giving tutoring lessons in Python to a professional who wants to use programming as part of his work. (He's an entrepreneur.) He is eager to understand functional and OO styles within Python--he keeps asking about the real benefit of each, not content with a superficial approach. I've explained about "encapsulation": gathering related functions together and minimizing coupling to the rest of the program. He asks "why do we encapsulate?" I've explained that one reason is to help we, the programmers, be confident that our code is correct. For example, in a class we try to isolate the implementation details from the rest of the program, and the compiler helps enforce that.So when we're writing our code and confirming to ourselves it's correct, we can make simplifying assumptions. We know the rest of the program won't modify our private variables and won't access us in any way other than the interface we've presented to the world. I explained that a large program is like a corporation, and pieces of the program are like individual employees. When we write a class or function, in a sense we "become" that employee and "forget about" a lot of the details of other employees. (i.e., encapsulation). Then has asked why functional programming is helpful. I explained about referential transparency. Say we're a function: then other "employees" (other functions) can trust us with simplifying assumptions, like no side-effects. Then this thought occurred to me, which is nifty but maybe not the whole story. """ Say we're a class. Then the simplifying assumptions of OO allow *us* to trust the *rest of the program* won't mess with us. Say we're a function. Then the simplifying assumptions of functional style help the *rest of the program* trust that *we* won't mess with it. """ D

10 14

Re: [Haskell-cafe] Informal modelling and simulation of protocols
by Doug McIlroy 12 Mar '19

12 Mar '19

> Is there some fantastic tool/library which already does everything I want? Have you looked into model checkers like Spin, which was developed for the very purpose of exhaustively checking protocols? See spinroot.com Doug McIlroy

5 5

Machine Learning Library in Haskell
by Heet Sankesara 12 Mar '19

12 Mar '19

Hello community, Myself Heet sankesara. I am a machine learning practitioner. I've been doing it for a year. I recently learned Haskell to implement Markov Logic Networks. I found the language intuitive. It is far easier to express logic and formulas in Haskell as compared to languages like Python or R. So I decided to do some data science using it but I couldn't because there is no library like Sklearn in Python. The few libraries I found are mostly disoriented and undermanaged. I want to work on machine learning library which can be used easily and efficiently by machine learning practitioners. It would be helpful for everyone to have a dedicated machine learning library. For a practitioner, it would be easier to tweak and test the model and try different algorithms quickly. For the community, the dedicated library leads the developers to focus on it and improve it which would result in a more efficient and flexible library. The list of algorithms I am planning to implement are as follows: 1. Linear and Logistic Regression 2. Ridge Regression 3. Perceptron 4. SVM classifier and regressor (Both Linear and Non-Linear) 5. Stochastic Gradient Descent 6. K-means clustering and KNN classifier 7. Naive Bayes 8. Decision trees 9. Random Forest 10. Gradient boosting 11. Ada boost 12. Voting classifier 13. Neural Network 14. Gradient Descent, Momentum, Nesterov accelerated gradient 15. Adaptive Moment Estimation (Adam optimizer) Please consider this idea for GSoC this year. I am be happy to talk about the idea and possible algorithms that can be implemented in the upcoming summer. With regards, Heet Sankesara

1 0

Haskell Symposium: Early Track due this Friday, March 15
by Richard Eisenberg 12 Mar '19

12 Mar '19

================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2019 Berlin, Germany 22--23 August, 2019 http://www.haskell.org/haskell-symposium/2019/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2019 will be co-located with the 2019 International Conference on Functional Programming (ICFP). **NEW THIS YEAR**: We will be using a lightweight double-blind reviewing process. See further information below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. Submission Details ================== Early and Regular Track ----------------------- The Haskell Symposium uses a two-track submission process so that some papers can gain early feedback. Strong papers submitted to the early track are accepted outright, and the others will be given their reviews and invited to resubmit to the regular track. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2019 will use 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 judgment 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. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Early track: Submission deadline: 15 March 2019 (Fri) Notification: 19 April 2019 (Fri) Regular track and demos: Submission deadline: 10 May 2019 (Fri) Notification: 21 June 2019 (Fri) Camera-ready deadline for accepted papers: 30 June 2019 (Sun) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell19.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). 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. Travel Support ============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://pac.sigplan.org) Proceedings =========== Accepted papers will be included in the ACM Digital Library. Authors must grant ACM publication rights upon acceptance (http://authors.acm.org/main.html) Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. All accepted papers and proposals will be posted on the conference website one week before the meeting. Publication date: The official publication date of accepted papers is the date the proceedings 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. Program Committee ================= Ki-Yung Ahn Hannam University Christiaan Baaij QBayLogic B.V. José Manuel Calderón Trilla Galois, Inc Benjamin Delaware Purdue University Richard Eisenberg (chair) Bryn Mawr College Jennifer Hackett University of Nottingham Kazutaka Matsuda Tohoku University Trevor McDonell Utrecht University Ivan Perez NIA / NASA Formal Methods Nadia Polikarpova University of California, San Diego Norman Ramsey Tufts University Christine Rizkallah University of New South Wales Eric Seidel Bloomberg LP Alejandro Serrano Mena Utrecht University John Wiegley Dfinity Foundation Thomas Winant Well-Typed LLP Ningning Xie University of Hong Kong If you have questions, please contact the chair at: rae(a)richarde.dev ================================================================================

1 0

Informal modelling and simulation of protocols
by P Orrifolius 11 Mar '19

11 Mar '19

Hi, this will probably be a somewhat rambling, open-ended question... my apologies in advance. There are some concrete questions after I explain what I'm trying to achieve, and some of them may even make sense! I'm planning on writing a multi-party, distributed protocol. I would like to informally model the protocol itself and the environment it would run in and then simulate it to see if it achieves what I expect. Then it would need to be implemented and tested of course. I think a formal, mathematical model of the protocol would be beyond my abilities. I'm looking for any advice or tool/library recommendations I can get on the modelling and simulating part of the process and how that work could be leveraged in the implementation to reduce the work and help ensure correctness. I have some ideas of how this could work, but I don't know if I'm approaching it with a suitably Haskell-like mindset... What I envisage at the moment is defining the possible behaviour of each party, who are not homogeneous, as well as things which form the external environment of the parties but will impact their behaviour. By external things I mean, for example, communication links which may drop or reorder packets, storage devices which may lose or corrupt data, machines that freeze or slew their clock... that sort of thing. I'm also picturing a 'universal coordinator' that controls interaction of the parties/environment during simulation. Modelling each party and external as a Harel-like statechart seems plausible. Perhaps some parts could be simpler FSMs, but I think many will be reasonably complex and involve internal state. It would be nice if the simulation could, to the limit of given processing time, exhaustively check the model rather than just randomly, as per quickcheck. If at each point the universal coordinator got a list of possible next states from each party/external it could simulate the simultaneity/sequencing of events by enumerating all combinations, of every size, of individual party/external transitions and then recursing with each separate combination applied as being the next set of simultaneous state transitions. To reduce the space to exhaustively search it would be nice if any values that the parties used, and were being tested by, were abstracted. Not sure what the technical term is but I mean asserting relationships between variables in a given domain, rather than their actual value. For example, imagine a distributed vote between two nodes where each node must vote for a random integer greater than their last vote. Each node is a party in the protocol. In the current branch of the exhaustive search of the protocol a relation between node 1's existing vote, v1, and node 2's existing vote, v2, has already been asserted: v1>v2. So when the coordinator enumerates the possibilities for sets of next-state transitions, with each node n asserting vn'>vn in their individual party state transition, it will prune any search branch which doesn't satisfy the union of the assertions (v1>v2, v1'>v1, v2'>v2), and recurse into the search branch alternatives with v1'<v2', or v1'=v2', or v1'>v2'. So, some questions... Is what I'm suggesting even vaguely sensible way to approach the problem in Haskell? Or am I getting carried away and some neat tricks zipping list monoids or something will get the job done? Is there some fantastic tool/library which already does everything I want? Are there any good tools or libraries in Haskell for defining and manipulating statecharts? The sessiontypes, and sessiontypes-distributed, libraries are cool, representing the protocol at the type level... but these only handle point-to-point, two-party protocols, right? I expect that extending them would be a _serious_ amount of work. Can quickcheck do the sort of exhaustive coverage testing that I'd like? Again, not sure of the correct terminology but can quickcheck generate tests at a variable-relation assertion level? I.e. inspect the operators and boolean tests over a domain (+, ==, >=, append, length, contains, etc) and explore test cases according to whether certain relations between variables hold. Any feelings/opinions about whether Oleg Kiselyov's Typed Tagless Final Interpreter (http://okmij.org/ftp/tagless-final/index.html) work might be a useful mechanism to define the behaviour of parties within the protocol (the statecharts, basically) and then have different interpreters that enable both the testing and implementation of the protocol, to keep them more closely aligned? I read that work years ago and have wanted to try it out ever since, so I may be overlooking the fact that it's totally unsuitable! Perhaps superseded now, but if it can allow more of the protocol to be expressed at the type level that would be good. Yeah, rambling. Sorry about that. Thanks! porrifolius

6 11