- Haskell-Cafe - Haskell.org

Request for Nominations to the GHC Steering Committee
by Alejandro Serrano Mena 13 Feb '21

13 Feb '21

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

1 0

Surprising lack of generalisation
by Tom Ellis 11 Feb '21

11 Feb '21

Dear all, I don't understand why the type of pBD defined in the where clause of pFG cannot be inferred to a general type in the presence of TypeFamilies. In particular I don't understand why nonetheless the type of pBD definied in the where clause of pF (only slightly simpler) *can* be inferred. Can anyone explain? Thanks Tom {-# LANGUAGE TypeFamilies #-} -- This code came up in the context of writing a parser, but that's -- not terribly important import Prelude hiding ((<$>)) data B = B data D f = F f | GF AP f | DF AM f data AM = AM data AP = AP pB :: Parser B pB = Parser -- Works fine pF :: Parser (D B) pF = pBD GF AP <|> pBD DF AM where pBD f p = f p <$> pB -- Shows the (presumably) inferred type for pBD pFWithType :: Parser (D B) pFWithType = pBD GF AP <|> pBD DF AM where pBD :: (t -> B -> b) -> t -> Parser b pBD f p = f p <$> pB -- One would hope this type would be inferred too pFGWithType :: Parser B -> Parser (D B) pFGWithType pBArg = pBD GF AP <|> pBD DF AM where pBD :: (t -> B -> b) -> t -> Parser b pBD f p = f p <$> pBArg -- But omitting it leads to a type error if TypeFamilies is enabled. -- There is no error if TypeFamilies is not enabled. pFG :: Parser B -> Parser (D B) pFG pBArg = pBD GF AP <|> pBD DF AM where pBD f p = f p <$> pBArg -- The specifics of the parser don't matter data Parser a = Parser (<|>) :: Parser a -> Parser a -> Parser a (<|>) _ _ = Parser (<$>) :: (a -> b) -> Parser a -> Parser b (<$>) _ _ = Parser

3 7

10 PhD studentships in Nottingham
by Graham Hutton 11 Feb '21

11 Feb '21

Dear all, The School of Computer Science at the University of Nottingham is seeking applications for 10 fully-funded PhD studentships: https://tinyurl.com/ten-phds-2021 Applicants in the area of the Functional Programming Laboratory (https://tinyurl.com/fp-notts) are strongly encouraged! If you are interested in applying, please contact a potential supervisor as soon as possible (the application deadline is 15th March): Thorsten Altenkirch - constructive logic, proof assistants, homotopy type theory, category theory, lambda calculus. Graham Hutton - mathematics of program construction, category theory, program correctness and efficiency, Haskell. Nicolai Kraus - homotopy type theory, higher category theory, constructive mathematics, and related topics. Henrik Nilsson - functional reactive programming, domain- specific languages, generalised notions of computation. The studentships are open to applicants of any nationality. Best wishes, Graham +-----------------------------------------------------------+ 10 Fully-Funded PhD Studentships School of Computer Science University of Nottingham, UK tinyurl.com/ten-phds-2021 Applications are invited for a number of fully funded PhD studentships offered by the School of Computer Science at the University of Nottingham, starting on 1st October 2021. The topics for the studentships are open, but should relate to the interests of one of the School’s research groups: Computational Optimisation and Learning Lab; Computer Vision Lab; Cyber Security; Functional Programming; Intelligent Modelling and Analysis; Mixed Reality Lab and Uncertainty in Data and Decision Making. The studentships are for three and a half years and include a stipend of (minimum) £15,609 per year and tuition fees. Applicants are normally expected to have a 2:1 Bachelor or Masters degree or international equivalent, in Computer Science or a related discipline, and must obtain the support of a potential supervisor in the School prior to submitting their application. Please contact potential supervisors at least two weeks prior to the closing date for applications. Informal enquiries may be addressed to Professor Tony Pridmore (tony.pridmore(a)nottingham.ac.uk) To apply, please submit the following items by email to Lindsay.Norman(a)nottingham.ac.uk: (1) A copy of your CV, including your actual or expected degree class(es), and results of all University examinations; (2) An example of your technical writing, such as a project report or dissertation; (3) Contact details for two academic referees - it is the applicant’s responsibility to ensure that references are requested and sent to Lindsay.Norman(a)nottingham.ac.uk; (4) A research proposal – max 2 x sides A4; (5) A covering letter, which must include the name of the member of staff who has agreed to support your application (without this your application cannot be considered), and the University’s job reference number (SCI1979). Closing date for applications: Monday 15th March 2021. +-----------------------------------------------------------+ 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

lexing nested comments in GHC/Parser/Lexer.x
by Benjamin Redelings 11 Feb '21

11 Feb '21

Hi, I notice that in Lexer.x for GHC nested comments are parsed using a special function, with the comment "nested comments require traversing by hand, they can't be parsed using regular expressions." While I see that nested comments can't be parsed using regular expressions, the lexer has a state stack, and so it seems like nested comments could be parsed by pushing a new "nested comment" state onto the lexer state every time a "{-" is encountered. But perhaps this is not done because its not clear how to make the entire comment into a single token that way? This might be a naive question -- I don't have that much experience with lexers. Thanks! -BenRI

2 1

International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) Prague
by matteo＠confscience.com 10 Feb '21

10 Feb '21

Call for papers ************************************************* International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) Prague - Czech Republic, October 14-15, 2021 https://confscience.com/rtatm/ Submission deadline: April 1, 2021 All papers accepted in RTATM 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: April 1, 2021 - Acceptance Notification: July 1, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The RTATM 2021 conference will be held in Conjunction with: International Conference on Applied Data Science and Intelligence (ADSI 2021) International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Modelling and Simulation Algorithms - Vehicular Wireless Medium Access Control - V2X communications - Routings and Protocols for Connected Vehicles - Mobility Models and Architectures - Distribution Strategies - Traffic Incident Management Systems - Bio-Inspired Approaches - Optimization and Collaboration - Automatic Control in Vehicular Networks - Energy-aware Connected Mobility - Programming Languages - Sustainable Transportation - Multimodal Transportation Networks and Systems - Systemsb Integration - Driver Behavior Models and Simulation - Human Factors and Travel Behaviour - Green Mobility - Regulations and Bylaws for Intelligent - Transportation and Mobility SMART TRANSPORTATION AND LOGISTICS - Mobility Management - Connected Vehicles - VANETs - Predictive Logistics - Spatio-Temporal Event Tracking - Decision Support Systems - Emergency Management - Logistics and E-Commerce - Supply Chain Design and Execution - Supply Chain Management - Advanced Planning Systems - Fleet Management - Multi-Agent Systems - Machine Learning for Smart Logistics - Intelligent Infrastructures - Real-time Analysis of Comprehensive Supply Chain Data - Smart Synchronization of Logistics Processes - New Approaches for Cost Transparency - Big Data for Smart Logistics - Logistics 4.0 - Mobile Networks - Next-Generation Smart Logistics - Performance Management Approaches - Tests and Deployment - Software Defined Networks - Smart Freight Management - Smart Shipment Management - Smart Warehousing - Smart Inventory management DATA AND SERVICES - Real-Time transportation Data Acquisition - Event Detection and Monitoring - Data Warehouses for connected mobility - Data mining and Data analytics - Data Worthiness in Connected Vehicles - Data Trustworthiness for effective transportation and mobility - Road Traffic Data Analytics - Structured and Unstructured Data for Connected Mobility - Volunteered Geographic Information (VGI) - Data Representation for Connected Mobility - Transportation Data Mining - Transportation and mobility Data Visualization - Cognitive and Context-aware Intelligence - Transportation Decision Support Systems - Mobility as a Service (MaaS) - Intelligent Transportation Services - Smart Mobility Services - Big Data and Vehicle Analytics - Massive Data Management - Collective and connected Intelligence - Next Generation Services - Driver Behaviour Analysis - Geo-Spatial Services - Service-Oriented Architecture (SOA) - Web and Mobile Services SAFETY, SECURITY, AND HAZARD MANAGEMENT - Security Issues in Vehicular Communications - Safety Applications of Connected Vehicles - Weather-related Safety solutions - V2V, V2I and I2V Road Safety Applications - Connected Mobility for Hazard Management - Risk Management - Road Traffic Crashes Analytics - Traffic Jam Prediction - Resource Allocation for Hazard Management - Trust and Privacy Issues in Logistics - Management of Exceptional Events - New approaches to Networking Security for Transportation Applications - Failure modes, human factors, software safety - Automated Failure Analysis - Performance and Human Error Analysis - Design and Reliability of Control Systems - Dispersion Modelling Software - Quantification of Risk *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=rtatm2021) All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/rtatm/ *************************************************************************** CONTACT For more information, please send an email to info-rtatm(a)confscience.com

1 0

21st Midlands Graduate School in the Foundations of Computing Science: Call for Participation
by Andrei Popescu 09 Feb '21

09 Feb '21

CALL FOR PARTICIPATION 21st Midlands Graduate School in the Foundations of Computing Science MGS 21 12-16 April 2021, virtually https://staffwww.dcs.shef.ac.uk/people/G.Struth/mgs21.html OVERVIEW The annual Midlands Graduate School in the Foundations of Computing Science (MGS) offers an intensive programme of lectures on the mathematical foundations of computing. It addresses first of all PhD students in their first or second year, but is open to anyone interested in its topics, from academia to industry and around the world. The MGS has been run since 1999 and is hosted alternately by the Universities of Birmingham, Leicester, Nottingham and Sheffield. MGS 21 is its 21st incarnation. Information about previous events can be found at the MGS web site http://www.cs.nott.ac.uk/MGS PROGRAMME MGS 21 consists of eight courses, each with four or five hours of lectures and a similar number of exercise sessions. Three courses are introductory; one is given by an invited lecturer. These should be attended by all participants. The remaining more advanced courses should be selected based on interest. MGS 21 aims at a mix of livestreamed and prerecorded lectures and livestreamed exercise sessions, with additional social online events. Invited lectures: Monads and Interactions Tarmo Uustalu, Reykjavik Introductory courses: Category Theory Jacopo Emmenegger, Birmingham Type Theory Thorsten Altenkirch, Nottingham Proof Theory Anupam Das, Birmingham Advanced courses: Homotopy Type Theory Nicolai Kraus, Nottingham Inductive and Coinductive Reasoning with Isabelle/HOL Andrei Popescu, Sheffield Effects and Call-by-Push-Value Paul Levy, Birmingham Formal Modelling and Analysis of Concurrent Systems Mohammad Mousavi, Leicester In addition we are organising a session where participants can briefly present and discuss their own research. A call will be made in March. REGISTRATION Participation at MGS 21 is free of charge, but selective. Requests must be submitted online via https://staffwww.dcs.shef.ac.uk/people/G.Struth/mgs21.html Registration deadline is April 1. ORGANISATION Please direct all queries about MGS 21 to Georg Struth. The Sheffield organisers are Harsh Beohar (H.Beohar(a)sheffield.ac.uk) Andrei Popescu (A.Popescu(a)sheffield.ac.uk) Georg Struth (G.Struth(a)sheffield.ac.uk)

1 0

Postdoc Position (up to 3 years) at St Andrews
by Christopher Brown 09 Feb '21

09 Feb '21

Dear All I have an opening for a postdoc to work on a new 3-year EPSRC project in the Programming Languages group at St Andrews. The deadline has been extended to the 26th February. Send me an email (cmb21(a)st-andrews.ac.uk<mailto:cmb21@st-andrews.ac.uk>) if you’d like to informally chat about the post. I’m very happy to chat to you. Thanks Chris Lecturer in Computer Science University of St Andrews Scotland -------------------- The Programming Languages Group seeks a Research Fellow to work on the newly funded 3-year EPSRC project, Energise: Refactorings and Skeletons for Energy-Aware Applications on High-Performance Embedded Systems. Embedded devices, such as mobile phones, drones, medical devices and even satellite imaging are now common place in society. These types of devices rely very heavily on battery power, contributing to climate change and global warming. Optimizing the software that runs on such devices for energy is a very challenging problem for software developers. The Energise project aims to address this issue by providing the developer with a refactoring tool to repurpose their software to make it consume less energy, and to do it in such a way that the code is guaranteed to still meet its specification. The Energise project aims to develop new, formally-motivated, refactorings and transformations that reduce energy consumption for embedded multi-core devices. This includes implementing refactorings for target languages such as C; proving general soundness of the refactorings using e.g. dependent types; developing new programming abstractions (skeletons) for common energy-reducing programming patterns; running experiments; writing proofs of correctness, etc. The post will require skills in formal semantics of programming languages, compilers, program transformation, lightweight formal methods (including, e.g. dependent types) and knowledge of parallelism and non-functional properties, including energy. Informal enquiries can be directed to Dr Chris Brown (cmb21(a)st-andrews.ac.uk<mailto:cmb21@st-andrews.ac.uk>). Applications are particularly welcome from women, people from the Black, Asian, Minority or Ethnic (BAME) community and other protected characteristics who are under-represented in research posts at the University. The University is committed to equality for all, demonstrated through our working on diversity awards (ECU Athena SWAN/Race Charters; Carer Positive; LGBT Charter; and Stonewall). More details can be found at http://www.st-andrews.ac.uk/hr/edi/diversityawards/. Interviews will be held on TBC. Please quote ref: AR2474MR Closing Date: 26 February 2021 School of Computer Science Salary: £33,797 - £36,914 per annum Fixed Term: 3 years Start: As soon as possible More details at: https://www.vacancies.st-andrews.ac.uk/Vacancies/W/6918/0/284952/889/resear…

1 0

tls 1.5.5
by Kazu Yamamoto 08 Feb '21

08 Feb '21

Hi all, I would like to announce that tls 1.5.5 has been released. The main purpose of this version is provide the Network.TLS.QUIC module. This is the first step to bring QUIC to the Haksell community. Changelog says: - QUIC support [#419](https://github.com/vincenthz/hs-tls/pull/419) [#427](https://github.com/vincenthz/hs-tls/pull/427) [#428](https://github.com/vincenthz/hs-tls/pull/428) [#430](https://github.com/vincenthz/hs-tls/pull/430) [#433](https://github.com/vincenthz/hs-tls/pull/433) [#441](https://github.com/vincenthz/hs-tls/pull/441) - Server ECDSA for P-256 [#436](https://github.com/vincenthz/hs-tls/pull/436) - Sort ciphersuites based on hardware-acceleration support [#439](https://github.com/vincenthz/hs-tls/pull/439) - Sending no_application_protocol [#440](https://github.com/vincenthz/hs-tls/pull/440) - Internal improvements [#426](https://github.com/vincenthz/hs-tls/pull/426) [#431](https://github.com/vincenthz/hs-tls/pull/431) Technical information can be found from the following blog posts: - Implementation status of QUIC in Haskell https://kazu-yamamoto.hatenablog.jp/entry/2020/02/18/145038 - Improving QUIC APIs of the TLS library in Haskell https://kazu-yamamoto.hatenablog.jp/entry/2020/09/16/150801 - The Current Plan for Haskell QUIC https://kazu-yamamoto.hatenablog.jp/entry/2020/10/23/141648 IMPORTANT NOTE: If you want to make "tls" faster, please install "cryptonite" with the "support_pclmuldq" flag: % cabal install cryptonite -f support_pclmuldq This enables hardware acceleration for the GCM part of AES-GCM. If you use old GCC, you need to disable the "use_target_attributes" flag: % cabal install cryptonite -f support_pclmuldq -f-use_target_attributes --Kazu

1 0

Haskell exercises for beginners
by Olaf Klinke 06 Feb '21

06 Feb '21

> Hello Haskell Café, > > I have been working on a website aimed at teaching programming and Computer > Science through quick examples. It is called "Computer Science by Example > <https://cscx.org/>;": https://cscx.org/ > > The exercises start very simple (e.g. read two numbers and print their sum > <https://cscx.org/add>;) then increase in difficulty and complexity > gradually (e.g. solving the change-making problem <https://cscx.org/cash>;). > The website has an "online judge" functionality where students can submit > their solutions which are tested and graded automatically without human > intervention. It currently supports solutions in *Haskell* and > additionally: Python, C, C++, C#, Java, JavaScript, Lua and Ruby. > > The exercises are useful not only to first time programmers, but also to > experienced programmers trying to learn a new language such as Haskell. > > Check it out at cscx.org. The exercises are freely available for anyone to > try. > > Best Regards, > Rudy Dear Rudy, thanks for sharing all these excercises. Automated grading has many advantages. The kind of automated grading cscx uses lets the program use stdin and stdout. However, for Haskell (and all other programming languages too) this means that students are, from the very beginning, forced to write parsers for the data the grading system gives on stdin. This means that either * You limit input data to stuff with built-in parsers (which you don't) * You teach proper parsing early, which is non-trivial, or * You permit the students develop an ad-hoc and potentially messy style of coping with unstructured input. In all the excercises I looked at, the grading specification does not say what the program should do with invalid input. Therefore messy ad- hoc parsing is what you should expect to see in, and in some cases comprise the largest part of, submitted solutions. Others may disagree whether this is to be prevented or not. I have limited experience in teaching. In some other CS courses the excercises give a program fragment which is to be completed by the student. In Haskell you could use property- based testing [1] like QuickCheck or doctests to do the heavy lifting for you, while at the same time presenting the students with an infinity of test cases. Another way might be to provide a random generator of structured test data, and the student's task is to write a program that echoes the random data together with the computed result. That way, you could still use the stdout-based automated grading. Example of QuickCheck-based grading: module Triple1 where -- Your task: Complete this function -- so that for example -- -- >>> triple 2 -- 6 -- >>> triple 123 -- 369 triple :: Integer -> Integer triple = undefined -- Automated grading appends the following and runs -- quickCheck prop_triple prop_triple :: Integer -> Bool prop_triple = triple n == 3*n Example of Random-based grading: module Triple1 where -- Your task: complete this function -- so that for example -- -- >>> pure 2 >>= triple -- 2 -- 6 triple :: Integer -> IO () triple n = do print n undefined -- Automated grading compiles -- main = (yourIntegerGenerator :: IO Integer) >>= triple -- and executes repeatedly. Kind regards Olaf [1] https://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/automatic-grading.pdf

1 0

International Conference on Applied Data Science and Intelligence - (ADSI 2021) Prague
by matteo＠confscience.com 06 Feb '21

06 Feb '21

Call for papers ************************************************* International Conference on Applied Data Science and Intelligence - (ADSI 2021) Prague- Czech Republic, October 14-15, 2021 https://confscience.com/adsi/ Submission deadline: April 1, 2021 All papers accepted in ADSI 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: April 1, 2021 - Acceptance Notification: July 1, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The ADSI 2021 conference will be held in Conjunction with: International Conference on Recent Theories and Applications in Transportation and Mobility (RTATM 2021) International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Theoretical Models - Spatial and temporal multi-models - Multi-dimensional data - Data acquisition and pre-processing - Data inference - Data Classification and Taxonomy - Data Metrics - New approaches for collaboration and competition - Self-organization, self-healing, fault-tolerance approaches - Spatial reasoning - Context awareness - Intelligent mobility - New approaches to supervised and unsupervised learning - New approaches for security, privacy, trust, and ethics in data science - Real-time data analytics - Multi-Agent Systems for data science - Distributed data analytics - Data authenticity - New theories and approaches for Deep learning - New approaches for Business Intelligence - Fuzzy logic - Decision trees - Support vector machines - Evolutionary computation - Statistical methods - Collaborative filtering - Data engineering - Content mining - Indexing schemes - Information retrieval - Metadata use and management INTELLIGENT DATA PROCESSING AND ANALYTICS - Multi-level data processing - Data analytics optimization - Smart data mining - Machine Learning - Deep Learning - Bio-Inspired Computing - Secure data analytics - Privacy in data analytics - Trust in Big Data - Business intelligence - Visualization Analytics - Intelligence as a Service (IaaS) - Data Science as a Service (DSaaS) - Natural Language Processing - Signal Processing - Simulation and Modeling - Data-Intensive Computing SYSTEMS AND INFRASTRUCTURES - Data storage infrastructure - Data warehouses - Data Query and Indexing Technologies - Software Defined Infrastructures - Software Defined Networks (SDN) - Distributed data systems - Smart grid computing - Intelligent data management - Big Data computing - Smart data networking - Internet of Things - Cyber Physical Systems - Blockchain - Fog and Edge intelligence - Parallel Computing systems - Open Source systems for data science - Embedded intelligence - Embedded data science - In-Memory computing - Intelligent drones - Internet of Drones - Real-time data acquisition systems APPLICATIONS - Intelligent Hazard management - Intelligent data science in healthcare - Intelligent data science in farming - Intelligent data science in Oil and Gas - Smart logistics - Intelligent data science in transportation - Intelligent data science in surveillance - Xtech (Fintech, Agritech, etc.) - Intelligent drones - Digital transformation - Bioinformatics - Marketing - Social Science - E-learning and E-services *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=adsi2021) All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/adsi/ *************************************************************************** CONTACT For more information, please send an email to info-adsi(a)confscience.com

1 0

Haskell exercises for beginners
by Rudy Matela 05 Feb '21

05 Feb '21

Hello Haskell Café, I have been working on a website aimed at teaching programming and Computer Science through quick examples. It is called "Computer Science by Example <https://cscx.org/>": https://cscx.org/ The exercises start very simple (e.g. read two numbers and print their sum <https://cscx.org/add>) then increase in difficulty and complexity gradually (e.g. solving the change-making problem <https://cscx.org/cash>). The website has an "online judge" functionality where students can submit their solutions which are tested and graded automatically without human intervention. It currently supports solutions in *Haskell* and additionally: Python, C, C++, C#, Java, JavaScript, Lua and Ruby. The exercises are useful not only to first time programmers, but also to experienced programmers trying to learn a new language such as Haskell. Check it out at cscx.org. The exercises are freely available for anyone to try. Best Regards, Rudy

1 0

International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) Prague
by matteo＠confscience.com 04 Feb '21

04 Feb '21

Call for papers ************************************************* International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) Prague - Czech Republic, October 14-15, 2021 https://confscience.com/rtatm/ Submission deadline: April 1, 2021 All papers accepted in RTATM 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: April 1, 2021 - Acceptance Notification: July 1, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The RTATM 2021 conference will be held in Conjunction with: International Conference on Applied Data Science and Intelligence (ADSI 2021) International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Modelling and Simulation Algorithms - Vehicular Wireless Medium Access Control - V2X communications - Routings and Protocols for Connected Vehicles - Mobility Models and Architectures - Distribution Strategies - Traffic Incident Management Systems - Bio-Inspired Approaches - Optimization and Collaboration - Automatic Control in Vehicular Networks - Energy-aware Connected Mobility - Programming Languages - Sustainable Transportation - Multimodal Transportation Networks and Systems - Systemsb Integration - Driver Behavior Models and Simulation - Human Factors and Travel Behaviour - Green Mobility - Regulations and Bylaws for Intelligent - Transportation and Mobility SMART TRANSPORTATION AND LOGISTICS - Mobility Management - Connected Vehicles - VANETs - Predictive Logistics - Spatio-Temporal Event Tracking - Decision Support Systems - Emergency Management - Logistics and E-Commerce - Supply Chain Design and Execution - Supply Chain Management - Advanced Planning Systems - Fleet Management - Multi-Agent Systems - Machine Learning for Smart Logistics - Intelligent Infrastructures - Real-time Analysis of Comprehensive Supply Chain Data - Smart Synchronization of Logistics Processes - New Approaches for Cost Transparency - Big Data for Smart Logistics - Logistics 4.0 - Mobile Networks - Next-Generation Smart Logistics - Performance Management Approaches - Tests and Deployment - Software Defined Networks - Smart Freight Management - Smart Shipment Management - Smart Warehousing - Smart Inventory management DATA AND SERVICES - Real-Time transportation Data Acquisition - Event Detection and Monitoring - Data Warehouses for connected mobility - Data mining and Data analytics - Data Worthiness in Connected Vehicles - Data Trustworthiness for effective transportation and mobility - Road Traffic Data Analytics - Structured and Unstructured Data for Connected Mobility - Volunteered Geographic Information (VGI) - Data Representation for Connected Mobility - Transportation Data Mining - Transportation and mobility Data Visualization - Cognitive and Context-aware Intelligence - Transportation Decision Support Systems - Mobility as a Service (MaaS) - Intelligent Transportation Services - Smart Mobility Services - Big Data and Vehicle Analytics - Massive Data Management - Collective and connected Intelligence - Next Generation Services - Driver Behaviour Analysis - Geo-Spatial Services - Service-Oriented Architecture (SOA) - Web and Mobile Services SAFETY, SECURITY, AND HAZARD MANAGEMENT - Security Issues in Vehicular Communications - Safety Applications of Connected Vehicles - Weather-related Safety solutions - V2V, V2I and I2V Road Safety Applications - Connected Mobility for Hazard Management - Risk Management - Road Traffic Crashes Analytics - Traffic Jam Prediction - Resource Allocation for Hazard Management - Trust and Privacy Issues in Logistics - Management of Exceptional Events - New approaches to Networking Security for Transportation Applications - Failure modes, human factors, software safety - Automated Failure Analysis - Performance and Human Error Analysis - Design and Reliability of Control Systems - Dispersion Modelling Software - Quantification of Risk *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=rtatm2021) All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/rtatm/ *************************************************************************** CONTACT For more information, please send an email to info-rtatm(a)confscience.com

2 1

TH: quoting name and value
by Sylvain Henry 02 Feb '21

02 Feb '21

Hi, I have the following kind of template haskell code: module Foo where foo :: String -> Name -> Q [Dec] foo str name = return [] module Bar where bar :: String bar = "whatever" module FooBar where import Foo import Bar foo bar 'bar It works great as in `foo` I can use both bar's Name and bar's value computed at compile time. But it's unsafe for my purpose because a user could call: `foo "fakeBarValue" 'bar` So the question is: is there a way to write `foo` so that it can only be used safely? If not, I guess it could be possible to add a new kind of quote to TH, something like: data Named a = Named Name a -- constructor not exported so that Named values can't be forged by users. [namedValue||bar||] :: Named String -- new quote What do you think? Thanks, Sylvain

2 2

Call for Papers: PACMPL issue ICFP 2021
by Sam Tobin-Hochstadt 02 Feb '21

02 Feb '21

PACMPL Volume 5, Issue ICFP 2021 Call for Papers Accepted papers to be invited for presentation at The 26th ACM SIGPLAN International Conference on Functional Programming To Be Held Virtualy http://icfp21.sigplan.org/ ### Important dates Submissions due: 2 March 2021 (Tuesday) Anywhere on Earth https://icfp21.hotcrp.com Author response: 20 April (Tuesday) - 23 April (Friday) 17:00 UTC Notification: 7 May (Friday) Final copy due: 30 June (Wednesday) Conference: 22 August (Sunday) - 27 August (Friday) ### 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 2021 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; macros; pattern matching; type systems; type inference; dependent types; session types; gradual typing; refinement types; interoperability; domain-specific languages; imperative programming; object-oriented programming; logic programming; probabilistic programming; reactive programming; generic programming; bidirectional programming. * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; runtime systems; 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; build systems; program synthesis. * Foundations: formal semantics; lambda calculus; program equivalence; rewriting; type theory; logic; category theory; monads; continuations; control; state; effects; names and binding; program verification. * 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; graphics and multimedia; GPU 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 2021 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such when submitted and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the associate editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is **Tuesday, March 2, 2021**, Anywhere on Earth (<https://www.timeanddate.com/time/zones/aoe>). 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>. There is a limit of **25 pages for a full paper or Functional Pearl** and **12 pages for an Experience Report**; in either case, the bibliography will not be counted against these limits. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. Supplementary material can and should be **separately** submitted (see below). See also PACMPL's Information and Guidelines for Authors at <https://pacmpl.acm.org/authors.cfm>. **Submission**: Submissions will be accepted at <https://icfp21.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 17:00 UTC on **Tuesday, April 20, 2021**, to read reviews and respond to them. **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). **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>. ### 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 2021. 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 PACMPL issue website to address common concerns. **PACMPL issue ICFP 2021 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. As a result of the review process, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on **May 7, 2021**. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. After four weeks (June 4, 2021), 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 four 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 2021 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 limit for the final versions of papers will be increased by two pages to help authors respond to reviewer comments and mandatory revisions: **27 pages plus bibliography for a regular paper or Functional Pearl, 14 pages plus bibliography for an Experience Report**. * 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, and authors are encouraged to publish their work under a CC-BY license. Gold Open Access guarantees permanent free online access to the definitive version in the ACM Digital Library, and the recommended CC-BY option also allows anyone to copy and distribute the work with attribution. 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. * 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. * 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. * Authors of each accepted submission are invited to attend and be available for the presentation of that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. ### 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. ### 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 end with the words "(Experience Report)" in parentheses. 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 Experience Report accepted to the PACMPL issue 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 the PACMPL issue, 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 to submit it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The associate editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Sukyoung Ryu (KAIST, South Korea) Accessibility Co-Chairs: Lindsey Kuper (UC Santa Cruz, USA), Kathrin Stark (Princeton University, USA) Artifact Evaluation Co-Chairs: Gabriel Scherer (INRIA Saclay, France), Brent Yorgey (Hendrix College, USA) Industrial Relations Co-Chairs: Alan Jeffrey (Roblox, USA), Simon Marlow (Facebook, England) Programming Contest Co-Organisers: Alex Lang, Jasper Van der Jeugt (Fugue, Switzerland) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Anders Miltner (University of Texas, USA) Student Volunteer Co-Chairs: Lily Bryant (University of British Columbia, Canada), Jaemin Hong (KAIST, South Korea), Hanneli Tavante (McGill University, Canada) Video Co-Chairs: Leif Andersen (Northeastern University, USA), Benjamin Chung (Northeastern University, USA) Workshops Co-Chairs: Leonidas Lampropoulos (University of Maryland, USA), Zoe Paraskevopoulou (Princeton University, USA) ### PACMPL Volume 5, Issue ICFP 2021 Associate Editor: Ronald Garcia, (University of British Columbia, Canada) Review Committee: Zena Ariola (University of Oregon, USA) Stephanie Balzer (Carnegie Mellon University, USA) Matteo Cimini (UMass Lowell, USA) Youyou Cong (Tokyo Institute of Technology, Japan) Harley Eades (University of Augusta, USA) Andrew Gordon (Microsoft Research & University of Edinburgh, United Kingdom) Benjamin Greenman (Brown University, USA) Arjun Guha (Northeastern University, USA) Jurriaan Hage (Utrecht, The Netherlands) Favonia (University of Minnesota, USA) Suresh Jagannathan (Purdue University, USA) Patricia Johann (Appalachian State University, USA) Ralf Jung (Max Planck Institute, Germany) Ekaterina Komendantskaya (Heriot-Watt, Scotland) Leonidas Lampropoulos (University of Maryland, USA) Kazutaka Matsuda (Tohoku University, Japan) Akimasa Morihata (Univeristy of Tokyo, Japan) Stefan Muller (Illinois Institute of Technology, USA) Max New (Wesleyan University, USA) Rishiyur Nikhil (Bluespec , USA) Cyrus Omar (University of Michigan, USA) Brigitte Pientka (McGill University, Canada) Norman Ramsey (Tufts University, USA) Christine Rizkallah (University of New South Wales, Australia) Taro Sekiyama (National Institute for Informatics, Japan) Eijiro Sumii (Tohoku University, Japan) Amin Timany (Aarhus University, Denmark) Mitchell Wand (Northeastern University, USA) Steve Zdancewic (University of Pennsylvania, USA)

1 0

PhD position at IMDEA Software Institute
by Niki Vazou 02 Feb '21

02 Feb '21

Hey Haskellers, Applications are invited for a PhD position at the IMDEA Software Institute, Madrid, Spain. The selected candidate will work under my supervision on the theory and practise of refinement types. Application deadline is March 15. More information are available here: https://software.imdea.org/open_positions/2021-02-phd-refinements.html Best, Niki Vazou

1 0

Project builds with stack, not with cabal. How to diagnose?
by Han Joosten 01 Feb '21

01 Feb '21

Dear Café, I have been building my project for quite some time now using Stack. That works fine. However, I also want to make sure cabal users can build it from source. Recently I have been trying to set this up using github actions. I use a matrix to build both with stack and with cabal. I use the same version of ghc. A recent build can be seen here: https://github.com/AmpersandTarski/Ampersand/runs/1756887612 I guess that the error is due to the fact that the used packages to build are somehow different between the stack build and the cabal build. Is there some way to find out what those differences are? Any help would be appreciated! Thanks Han Joosten

3 3

PSA: IRC #haskell-ide-engine has moved to #haskell-language-server
by Alan & Kim Zimmerman 30 Jan '21

30 Jan '21

Given haskell-ide-engine is retired, we have moved the IRC channel to something more appropriate. Alan

1 0

Compilation of large data
by Dušan Kolář 29 Jan '21

29 Jan '21

Dear Café, How can I compile large data in the source code? The data structure contains a few numerical and String constants and a long list of structures (containing two short lists of Strings). If I use ghci, it's fine, no problem (until some size). When I want to compile then I run out of memory (32GB, plus 32GB swap) on arch linux. Yes, machine with 256GB solved temporarily the problem, but only temporarily. The data is generated (about 10.000 elements for the list and more). Should it be read from the file during the runtime? Should the structure be somehow decoupled (to small lists, each of them in a separate file)? Or there is no way, how to make it work... :-( If I use different input, a bit smaller, which I can compile, the resulting binary is rather small, less than 7MB. Regards Dušan

4 4

Take over maintainership binary search
by Jappie Klooster 28 Jan '21

28 Jan '21

Hi, I wish to take over the maintainership of the binary search package. The company I work for (riskbook) currently uses binary search. However the current version doesn't build from hackage because ghc changed how setting files are used, so I made a PR simply deleting that: https://github.com/nushio3/binary-search/pull/3 That has been several months ago and now I'm running against the same issue. There hasn't been a from the author (nushio3), and the email address CC'ed in here are full according to gmail. With regards, Jappie Klooster Riskbook | Software engineer e jappie(a)riskbook.com p +31644237437 Riskbook is a Limited Company (Company No. 10475714) registered at 1 Adamson Drive, Horsehay, Telford, TF4 3UJ, United Kingdom. All contents of this email should be treated as private and confidential unless otherwise stated.

3 3

explicit type for "local" functions
by Jean-Marc Alliot 27 Jan '21

27 Jan '21

Just a short and probably simple question. Let's consider the following function: collatz n = let coll (n,cpt) | n==1 = (1,cpt) | even n = coll (div n 2,cpt+1) | odd n = coll (div (n*3+1) 2,cpt+1) in snd (coll (n,0)) It is easy to set explicitly the type of "collatz" by writing before the function definition: collatz :: Integer->Int But can I set explicitly the type of the "local" function "coll" ? Thanks

2 1

Re: [Haskell-cafe] A quick question about distribution of finite maps.
by Olaf Klinke 26 Jan '21

26 Jan '21

> I find the idea that finite sets and functions may be > represented in Haskell very attractive in general Okay, so the Map was a red herring. It is only one possible implementation of the mathematical concept you are after. To be more clear, let's use Map with capital M whenever we mean the data structure and "map" or "function" whenever we mean the mathematical concept. What you really want is functions between finite sets. Maps do not, in general, represent functions in the Control.Category sense. That got me hooked onto the Kleisli thing. Classical case of nerd-sniping. But you want to deviate from Control.Category and that's perfectly fine because we know the math works. > This establishes a Cartesian closed category of somewhat idealized > entities. Can > the realization of this category in Haskell be perfected to exclude > pathologies > by construction? I think you need dependent types, but let's try. import Data.Map (Map) import qualified Data.Map.Strict as Map import Data.Set (Set) import qualified Data.Set as Set -- Note: One could also define -- FiniteFunction a b = (Set a, a -> b) -- hence the Map in your OP was misleading. newtype FiniteFunction a b = FMap {asMap :: Map a b} domain :: FiniteFunction a b -> Set a domain = Map.keysSet . asMap codomain :: Ord b => FiniteFunction a b -> Set b codomain = Set.fromList . Map.elems . asMap unsafeRunFiniteFunction :: Ord a => FiniteFunction a b -> a -> b unsafeRunFiniteFunction = (assertDomain.) . flip Map.lookup . asMap where assertDomain (Just b) = b assertDomain Nothing = error "argument outside of domain" -- | @(unsafeRunFiniteFunction f) `restrictedTo` (domain f) = f@ restrictedTo :: (a -> b) -> Set a -> FiniteFunction a b f `restrictedTo` dom = FMap (Map.fromSet f dom) -- | (.) of the category. -- 'id' on dom is @id `restrictedTo` dom@ compose :: (Ord a, Ord b, Ord c) => FiniteFunction b c -> FiniteFunction a b -> FiniteFunction a c compose (FMap g) (FMap f) = FMap (fmap g' f) where g' b = case Map.lookup b g of Nothing -> error "type mismatch between domain and codomain" Just c -> c {-- Now to the CCC structure. At this point we run into a problem: Categorically, if f :: A -> (C^B) and we uncurry it, then the domain of (uncurry f) is a square, the cartesian product of A and B. Trying to curry a function whose domain is a proper subset of the cartesian product of A and B should be a type error in my opinion, but Haskell's type system can not express this. I imagine failure of this property may lead to unexpected results when used in conjunction with 'compose'. But maybe currying functions with non-square domain is a desirable feature. If so, remove assertUncurried below. --} -- | @'isSquare' setOfPairs = True@ iff @setOfPairs@ -- is of the form -- @Set.fromList [(a,b) | a <- setA, b <- setB]@. isSquare :: (Ord a, Ord b) => Set (a,b) -> Bool isSquare setOfPairs = let fstProj = Set.map fst setOfPairs sndProj = Set.map snd setOfPairs in all (\a -> all (\b -> (a,b) `Set.member` setOfPairs) sndProj) fstProj isUncurried :: (Ord a, Ord b) => FiniteFunction (a,b) c -> Bool isUncurried = isSquare . domain -- | Beware: we can not express in the type system that -- for all keys @a@ the 'domain' :: Set b of the value under @a@ -- is the same Set, which is a prerequisite for the CCC operation. -- Hence we can not guarantee that the resulting 'domain' 'isSquare'. uncurryFiniteFunction :: (Ord a, Ord b) => FiniteFunction a (FiniteFunction b c) -> FiniteFunction (a,b) c uncurryFiniteFunction = FMap . Map.foldMapWithKey unc . asMap where unc a (FMap bc) = Map.mapKeysMonotonic ((,) a) bc -- | likewise, if the 'domain' of the uncurried function -- fails 'isSquare' then the result is not a well-defined -- higher-order 'FiniteFunction'. curryFiniteFunction :: (Ord a, Ord b) => FiniteFunction (a,b) c -> FiniteFunction a (FiniteFunction b c) curryFiniteFunction f@(FMap ab_c) = assertUncurried (FMap a_bc) where filterFst a = Map.foldMapWithKey (\ab c -> if fst ab == a then Map.singleton (snd ab) c else Map.empty) ab_c as = Map.foldMapWithKey (\(a,_) _ -> Set.singleton a) ab_c a_bc = Map.fromSet (FMap . filterFst) as assertUncurried = if isUncurried f then id else error "not an uncurried function"

2 2

Puzzling "Reduction stack overflow" error message
by CASANOVA Juan 24 Jan '21

24 Jan '21

Hello Haskell Cafe, I almost feel guilty for posting this since I almost never read messages from this list. But I guess others do and do so because they want to so it's an asymmetry that is fine, and which probably won't be like that forever (I'll get to reading them again at a different stage of my life I'm feeling better). I also have very bad experience with asking "complex" Haskell questions in Stack Overflow, with people either not replying or replying stuff that indicates they did not understand the question. Digression aside, I have encountered this error before and it is a nasty one, but this time I am just wildly puzzled by what it's trying to tell me. This is part of a very large program (and I think the huge stack of types and instances is what is hiding the problem here), but I'll try to condense it into a small bit. The following function I have is the one that throws the error: resolve_to_constraints_metacnf :: SOMetaSignature -> SOMetaCNF -> Computation (Maybe SOMetaUnifSystem) resolve_to_constraints_metacnf sig cnf = result where f1 = (ADDirect <$>) :: SOMetaliteral -> SOMetaUnifLiteral; f2 = (f1 <$>) :: [SOMetaliteral] -> [SOMetaUnifLiteral]; f3 = (f2 <$>) :: [[SOMetaliteral]] -> [[SOMetaUnifLiteral]]; ucnf = f3 cnf :: [[SOMetaUnifLiteral]]; resolved = res_computeresolve SOResGreedyFactorH ucnf :: StateT uv Computation (Maybe SOMetaUnifSystem); runstated = runStateT resolved (UnifVar 0); result = fst <$> runstated The error starts as follows: Reduction stack overflow; size = 201 When simplifying the following type: Eq OFunction The rest is the standard for this type of errors. OFunction does not appear explicitly on my function signature, but if we look at the definitions of SOMetaSignature, SOMetaCNF, SOMetaLiteral, SOMetaUnifLiteral and SOMetaUnifSystem, we see they are type aliases for parameterised types, all of which include OFunction as one of their parameters. Here's an example: type SOMetaUnifLiteral = Literal (AtomDependant CAtomPF CTermF LambdaCNF SOPredicate OPredicate OFunction OVariable SOAMVariable SOMVariable UnifVariable) (Yes, I know how tedious it is to have so many type parameters, tell me about it). And perhaps also relevantly, this is the signature of res_computeresolve (which type checks): res_computeresolve :: (ResLiteral l r mt, Heuristics h [Literal l] () (ResStep l) m) => h -> [[Literal l]] -> mt m (Maybe r) (note, might be relevant, that ResLiteral requires mt to be a MonadTrans and MFunctor, which StateT, the type it gets instantiated to in the calling function, is. m gets instantiated to Computation which is a Monad I implemented myself (and works fine).) Now, the natural thing to think is to track the Constraints to find which one is asking for an Eq OFunction and how that works. It definitely is a constraint that I use all over the place. But, here is the puzzling thing. Eq OFunction is clearly implemented. OFunction is a really simple type. Here is the basic definition: data OFunction = OFun Int Int deriving (Eq, Ord) So, why is it having such a hard time proving Eq OFunction, if it is a really simple type with a derived instance of Eq (which has worked thus far without any issues)? My suspicion is that the message is bugged, and the stack overflow is not on that specific instance, but rather on some type variable on a larger instance that it can never entirely instantiate no matter how many constraints it resolves. This is why I added those inline type signatures to the triple fmap, to try to help GHC know what the types should look like. But I am still getting the error, and I really don't know what else to do now. Sorry for the long message, but since I don't know where the error is coming from, I wanted to give some context, and my entire program is tens of thousands of lines of codes by now... I hope people are able to skim and find the relevant bit that tells them what's likely the stupid mistake I am making. Thanks in advance, Juan. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 3

Re: [Haskell-cafe] stack: duplicate modules in library
by Chris Reade 22 Jan '21

22 Jan '21

Solved - thanks to suggestions from Sebastiaan Joosten. A syntax error (missing hyphens) in package.yaml file was creating duplicates in the .cabal file. So nothing to do with cached binary at all. Chris > On 21 Jan 2021, at 13:57, Chris Reade <chrisreade(a)mac.com> wrote: > > I have come across a problem with haskell stack putting duplicate modules in a library. > > On "stack build" I get > > "Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8.4: Duplicate modules in library:..” > > This may have originally been caused when I changed capitalisation of a filename, but changing back did not resolve the problem. > > My question is how do I get rid of the library so I can rebuild? > I tried "stack purge” and also removing ~/.stack with no luck > (the latter causes a new ghc download on stack build, but with the same message afterwards) > > I know the source modules are fine because they all load in "stack ghci” > Is there some other directory that stack/cabal uses for binary cache that I can safely delete? > > Chris > > >

1 0

[Lambda Days + TFP + TFPIE 2021] call for participation
by Peter Achten 22 Jan '21

22 Jan '21

------------------------------------------------------------------------------- C A L L F O R P A R T I C I P A T I O N 8th Lambda Days + 10th International Workshop on Trends in Functional Programming in Education + 22nd Symposium on Trends in Functional Programming 16 - 19 February 2021 https://www.lambdadays.org/lambdadays2021 ------------------------------------------------------------------------------- The programmes for Lambda Days, TFPIE, and TFP are online: - Lambda Days overall program at: https://www.lambdadays.org/lambdadays2021 - TFPIE specific program at: https://wiki.tfpie.science.ru.nl/TFPIE2021 - TFP specific program at: http://tfp2021.org/ (all times are in Central European Time Zone: 12.00:18.00 (CEST)) Lambda Days is a place where academia meets industry, where research and practical application collide. Once again Lambda Days joins forces with Trends in Functional Programming (TFP) and Trends in Functional Programming in Education (TFPiE) so that for four days you can be at the centre of the functional programming world. The program has a lot of interesting talks, possibilities for interaction, and a host of keynote presentations: Lambda Days keynote speakers: ----------------------------- Perdita Stevens, Pat Hannahan, Simon Peyton Jones, Andy Gordon, Philip Wadler. Trends in Functional Programming in Education keynote speakers: --------------------------------------------------------------- Francesco Cesarini, Simon Thompson, and Bartosz Milewski. Trends in Functional Programming keynote speaker: ------------------------------------------------- Zhenjiang Hu. Thanks to a generous sponsor, TFP has a limited number of free tickets for PhD, Msc, Bsc students with an interest in functional programming. To apply, send a mail to the program chair of TFP, Viktória Zsók (zsv(a)elte.hu) with your name, university, 2-3 lines of motivation, and a valid student card photo to get the registration code. Tickets will be delivered in the order of application.

1 0

Munich Virtual Haskell Meeting, 2021-01-25 @ 19:30
by Leah Neukirchen 22 Jan '21

22 Jan '21

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, January 25 on Google Meet. For details see here: **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: http://muenchen.haskell.bayern/dates.html A Google Meet link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

stack: duplicate modules in library
by Chris Reade 22 Jan '21

22 Jan '21

I have come across a problem with haskell stack putting duplicate modules in a library. On "stack build" I get "Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8.4: Duplicate modules in library:..” This may have originally been caused when I changed capitalisation of a filename, but changing back did not resolve the problem. My question is how do I get rid of the library so I can rebuild? I tried "stack purge” and also removing ~/.stack with no luck (the latter causes a new ghc download on stack build, but with the same message afterwards) I know the source modules are fine because they all load in "stack ghci” Is there some other directory that stack/cabal uses for binary cache that I can safely delete? Chris

2 1

Bind the GAP barely legible?
by Viktor Dukhovni 20 Jan '21

20 Jan '21

I tried to read "Bind the GAP": https://bindthegap.news/issues.html but the colours, fonts, and layout are so disorienting that I'm afraid it is just too much work to make much sense of it. Am I just too old-fashioned in my expectations, or do others alos find that the festive artwork completely overwhelms the content in this publication? If there's anyone on this list who's involved in producing the publication, please consider drastically dialing back the decorations. -- Viktor.

10 10

Time to vote on possible haskell-language-server logos
by Alan & Kim Zimmerman 19 Jan '21

19 Jan '21

As we announced in December last year, we are looking for a logo for the haskell language server. We now have a selection of candidates, and the voting is open [1] You can vote for as many options as you like. We are closing the poll on 26 Jan (a week from now). Make your preference known, you will hopefully be seeing it a *lot*. Alan [1] https://github.com/haskell/haskell-language-server/issues/694#issuecomment-…

1 0

2nd Call for Participation: BOB 2021 (February 26, online)
by Stefan Wehr 11 Jan '21

11 Jan '21

================================================================================ BOB 2021 Conference “What happens if we simply use what’s best?” February 26, 2021, online (UTC+0100) http://bobkonf.de/2021/ Program: http://bobkonf.de/2021/program.html Registration: http://bobkonf.de/2021/registration.html ================================================================================ BOB conference is a place for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experience. The program features 14 talks and 8 tutorials on current topics: http://bobkonf.de/2021/program.html The subject range includes functional programming, logic programming, revision control, formal methods, mindfulness, event sourcing, front-end development, and more. Jeremy Gibbons will give the keynote talk. BOB 2021 will take place online. We are working towards fostering lively exchange of exciting ideas and enable meaningful social interactions. Registration is open online: http://bobkonf.de/2021/registration.html Registration is €30 for a regular ticket, €15 for a student ticket. (If you need financial aid, let us know.) We intend to make this the most diverse, colorful, fun BOB ever!

1 0

Re: [Haskell-cafe] A quick question about distribution of finite maps.
by Olaf Klinke 11 Jan '21

11 Jan '21

> Hello! > > Finite maps from `"containers" Data.Map` look like they may form a > Cartesian closed category. So it makes sense to ask if the rule _α ⇸ > (β ⇸ γ) ≡ ⟨α; β⟩ ⇸ γ ≡ ⟨β; α⟩ ⇸ γ ≡ β ⇸ (α ⇸ γ)_ that holds in such > categories does hold for finite maps. Note that, a map being a > functor, this also may be seen as _f (g α) ≡ g (f α)_, which would > work if maps were `Distributive` [1]. > > It looks to me as though the following definition might work: > > distribute = unionsWith union . mapWithKey (fmap . singleton) > > — And it works on simple examples. _(I checked the law `distribute ∘ > distribute ≡ id` — it appears to be the only law required.)_ > > Is this definition correct? Is it already known and defined > elsewhere? > > [1]: > https://hackage.haskell.org/package/distributive-0.6.2.1/docs/Data-Distribu… Hi Ignat, TL;DR: No and no. The documentation says that every distributive functor is of the form (->) x for some x, and (Map a) is not like this. If Maps were a category, what is the identity morphism? Let's put the Ord constraint on the keys aside, Tom Smeding has already commented on that. Next, a Map is always finite, hence let's pretend that we are working inside the category of finite types and functions. Then the problems of missing identity and missing Ord go away. Once that all types are finite, we can assume an enumerator. That is, each type x has an operation enumerate :: [x] which we will use to construct the inverse of flip Map.lookup :: Map a b -> a -> Maybe b thereby showing that a Map is nothing but a memoized version of a Kleisli map (a -> Maybe b). Convince yourself that Map concatenation has the same semantics as Kleisli composition (<=<). Given a Kleisli map k between finite types, we build a Map as follows. \k -> Map.fromList (enumerate >>= (\a -> maybe [] (pure.(,) a) (k a))) With that knowledge, we can answer your question by deciding: Is the Kleisli category of the Maybe monad on finite types Cartesian closed? Short answer: It is not even Cartesian. There is an adjunction between the categories (->) and (Kleisli m) for every monad m, where * The left adjoint functor takes types x to x, functions f to return.f * The right adjoint functor takes types x to m x, Kleisli maps f to (=<<) f Right adjoint functors preserve all existing limits, which includes products. Therefore, if (Kleisli m) has binary products, then m must preserve them. So if P x y was the product of x and y in Kleisli m, then m (P x y) would be isomorphic to (m x,m y). This seems not to hold for m = Maybe: I can not imagine a type constructor P where Maybe (P x y) ~ (Maybe x,Maybe y). In particular, P can not be (,). The only sensible Kleisli projections from (x,y) would be fst' = return.fst and snd' = return.snd. Now think of two Kleisli maps f :: Bool -> Maybe x, g :: Bool -> Maybe y. Assume that f True = Just x for some x and g True = Nothing. In order to satisfy g True = (snd' <=< (f&&&g))True, the unique pair arrow (f&&&g) would need to map True to Nothing, but then f True = (fst' <=< (f&&&g)) True can not hold. We conclude that (Kleisli Maybe) does not even have categorical products, so asking for Cartesian closure does not make sense. You might ask for a weaker property: For every type x, ((,) x) is a functor on (Kleisli Maybe). Indeed, the following works because ((,) x) is a polynomial functor. fmapKleisli :: Functor m => (a -> m b) -> (x,a) -> m (x,b) fmapKleisli f (x,a) = fmap ((,) x) (f a) Thus you may ask whether this functor has a right adjoint in the Kleisli category of Maybe. This would be a type constructor g with a natural isomorphism (x,a) -> Maybe b ~ a -> Maybe (g b). The first thing that comes to mind is to try g b = x -> Maybe b and indeed djinn can provide two functions going back and forth that have the right type, but they do not establish an isomorphism. I doubt there is such a right adjoint g, but can not prove it at the moment. The idea is that a function (x,a) -> Maybe b may decide for Nothing depending on both x and a, and therefore the image function under the isomorphism must map every a to Just (g b) and delay the Nothing-decision to the g b. But for the reverse isomorphism you can have functions that do not always return Just (g b) and there is no preimage for these. Regards, Olaf

5 16

A quick question about distribution of finite maps.
by Ignat Insarov 10 Jan '21

10 Jan '21

Hello! Finite maps from `"containers" Data.Map` look like they may form a Cartesian closed category. So it makes sense to ask if the rule _α ⇸ (β ⇸ γ) ≡ ⟨α; β⟩ ⇸ γ ≡ ⟨β; α⟩ ⇸ γ ≡ β ⇸ (α ⇸ γ)_ that holds in such categories does hold for finite maps. Note that, a map being a functor, this also may be seen as _f (g α) ≡ g (f α)_, which would work if maps were `Distributive` [1]. It looks to me as though the following definition might work: distribute = unionsWith union . mapWithKey (fmap . singleton) — And it works on simple examples. _(I checked the law `distribute ∘ distribute ≡ id` — it appears to be the only law required.)_ Is this definition correct? Is it already known and defined elsewhere? [1]: https://hackage.haskell.org/package/distributive-0.6.2.1/docs/Data-Distribu…

4 7

GHC / macports / Big Sur
by Sean Matthews 09 Jan '21

09 Jan '21

It may be that someone has already asked this question, but I am having a problem (= it does not work) installing GHC using macports. Pure vanilla Mac/macports, with a few standard installed packages, but deliberately as few manual interventions as possible. Does the group have any advice? Thanks, Sean Matthews PS this is what macports says: r.packages.macports.org/stack ---> Attempting to fetch stack-2.5.1_0.darwin_20.x86_64.tbz2 from https://cph.dk.packages.macports.org/stack ---> Building stack Error: Failed to build stack: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_stack/stack/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port ghc failed ---> Some of the ports you installed have notes: pinentry-mac has the following notes: If you previously didn't have pinentry or gpg-agent installed and pinentry-mac has been installed as a dependency of gpg-agent, you don't need to do anything to use pinentry-mac. If you want to switch to the GTK2, ncurses or Qt4 based pinentry program, please install pinentry with the correct use flags and follow the instructions below substituting the pinentry-mac program path with /opt/local/bin/pinentry. If you previously had pinentry and gpg-agent installed and would like to switch to pinentry-mac, you will have to set it as your pinentry program in $HOME/.gnupg/gpg-agent.conf. Add the following line to the mentioned file: pinentry-program /Applications/MacPorts/pinentry-mac.app/Contents/MacOS/pinentry-mac Be sure to comment previous "pinentry-program" lines, for example: pinentry-program SAMPLE becomes #pinentry-program SAMPLE Afterwards, run killall -HUP gpg-agent or simply log out and back in again. -- Sean Matthews seanmatthews1(a)gmail.com / +49 163 803 1396

2 1

F-IDE 2021 - 2nd Call for Papers
by Andrei Paskevich 08 Jan '21

08 Jan '21

****************************************************************** F-IDE 2021: 6th Workshop on Formal Integrated Development Environment Affiliated with NASA Formal Methods 2021 May 24-25, 2021 -- held online https://cister-labs.pt/f-ide2021 ****************************************************************** Keynotes * Prof. Jan Friso Groote, Eindhoven Univ. of Technology, the Netherlands * Benoît Rognier, Edukera, France Important Dates * Abstract submission: Mon, Feb 22, 2021 * Full paper submission: Mon, Mar 1, 2021 * Notification: Mon, Apr 19, 2021 * Camera-ready: Mon, May 3, 2021 * Workshop: May 24-25, 2021 Overview High levels of safety, security, and privacy standards require the use of formal methods to specify and develop compliant software (sub)systems. Any standard comes with an assessment process, which requires a complete documentation of the application to ease the justification of design choices and the review of code and proofs. Ideally, an F-IDE dedicated to such developments should comply with several requirements. The first one is to associate a logical theory with a programming language, in a way that facilitates the tightly coupled handling of specification properties and program constructs. The second is to offer a language and/or an environment simple enough to be usable by most developers, even if they are not fully acquainted with higher-order logics or set theory, in particular by making development of proofs as easy as possible. The third is to offer automated management of application documentation. It may also be expected that developments done with such an F-IDE are reusable and modular. Tools for testing and static analysis may be embedded within F-IDEs to support the assessment process. Topics The workshop is open to contributions on all aspects of a system development process, including specification, design, implementation, analysis, and documentation. It welcomes the presentation of tools, methods, techniques, and experiments. Topics of interest include, but are not limited to, the following: * F-IDE building: design and integration of languages, development of user-friendly front-ends * How to make high-level logical and programming concepts palatable to industrial developers * Integration of object-oriented and modularity features * Integration of static analyzers * Integration of automated proof tools, theorem provers, and testing tools * Documentation tools * Impact of tools on certification * Experience reports on developing F-IDEs * Experience reports on using F-IDEs * Experience reports on formal methods-based assessments in industrial applications Submission Guidelines We accept both long (15 pages) and short (6 pages) paper submissions. The page limit does not include the bibliography. Submitted papers must present original contributions whose main results and conclusions have not been published or submitted elsewhere. Each submission will be reviewed by at least three members of the Program Committee. We expect that one author of every accepted paper will present their work at the workshop. Submitted papers must be written in English and follow the EPTCS LaTeX format (http://style.eptcs.org) Authors are invited to submit the following types of contributions: * Research papers providing new concepts and results * Experience reports * Position papers and research perspectives * Tool presentations Papers should be submitted via EasyChair at F-IDE 2021's workshop page: https://easychair.org/conferences/?conf=f-ide2021. Preliminary proceedings will be made available in electronic form at the workshop. Post-proceedings will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Program Committee * Andrew Reynolds, University of Iowa, USA * Damien Doligez, Inria, France * Bernhard Rumpe, RWTH Aachen University, Germany * Carlo A. Furia, Chalmers University of Technology, Sweden * César Muñoz, NASA Langley, USA * Cinzia Bernardeschi, University of Pisa, Italy * Claudio Sacerdoti Coen, University of Bologna, Italy * Enrico Tassi, Inria, France * François Pessaux, ENSTA ParisTech, France * José Creissac Campos, University of Minho, Portugal * Kenneth Lausdahl, Aarhus University, Denmark * Laurent Voisin, Systerel, France * Lucas Wagner, Collins Aerospace, USA * Makarius Wenzel, sketis.net * Markus A. Kuppe, Microsoft Research, USA * Mattias Ulbrich, Karlsruhe Institute of Technology, Germany * Pierre-Yves Strub, LIX, École Polytechnique, France * Rosemary Monahan, Maynooth University, Ireland * Silvia Lizeth Tapia Tarifa, University of Oslo, Norway * Simão Melo de Sousa, Universidade Beira Interior, Portugal * Stefan Mitsch, Carnegie Mellon University, USA * Stephan Merz, Inria, France * Virgile Prevosto, Institut List, CEA Tech, Université Paris-Saclay, France * Yannick Moy, AdaCore, France * Yi Zhang, Massachusetts General Hospital, USA PC Chairs * Andrei Paskevich, Université Paris-Saclay, France * José Proença, CISTER/ISEP, Portugal Steering Committee * Catherine Dubois, Samovar, ENSIIE, France * Paolo Masci, US National Institute of Aerospace (NIA), USA * Dominique Méry, LORIA, Université de Lorraine, France

1 0

[TFP'21] final call for papers: Trends in Functional Programming 2021, 17-19 February (online event with Lambda Days 2021 & TFPIE 2021)
by Peter Achten 08 Jan '21

08 Jan '21

------------------------------------------------------------------------- Final call for papers 22nd Symposium on Trends in Functional Programming tfp2021.org *deadline: January 15 2021* ------------------------------------------------------------------------- Did you miss the deadline to submit a paper to Trends in Functional Programming http://tfp2021.org/? No worries -- it's not too late! Submission is open until January 15th 2021, for a presentation slot at the event and post-symposium reviewing. 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. * TFP offers a supportive reviewing process designed to help less experienced authors succeed, with two rounds of review, both before and after the symposium itself. Authors have an opportunity to address reviewers' concerns before final decisions on publication in the proceedings. * TFP offers two "best paper" awards, the John McCarthy award for best paper, and the David Turner award for best student paper. * TFP is co-located with Lambda Days in beautiful Krakow. Lambda Days is a vibrant developer conference with hundreds of attendees and a lively programme of talks on functional programming in practice. Due to the covid pandemic, the event is online with a lot of attention to interaction and getting to socialize with the community. Important Dates --------------- Submission deadline for pre-symposium review: 20th November, 2020 -- passed -- Submission deadline for draft papers: 15th January, 2021 Symposium dates: 17-19th February, 2021 Visit http://tfp2021.org/ for more information.

1 0

How to do reversible parsing?
by Askar Safin 07 Jan '21

07 Jan '21

Hi. How to do deterministic reversible parsing in Haskell? Please, point me to some libs or tools. Or give some advice on how to write such lib or tool. (Also, I am interested in solutions for C or C++.) Now let me explain my task in detail. I am interested in formal math. I am going to develop various proof checkers. In particular, I want to develop my PTS checker ( https://en.wikipedia.org/wiki/Pure_type_system ). Here is example of existing PTS checker: http://web.archive.org/web/20180924133846/http://www.cs.kun.nl/~janz/yarrow/ . Here is example of input this checker accepts (taken from manual): Var (+) : Nat -> Nat -> Nat Def double := \x:Nat. x+x Def S := (+) one Also, I want to develop something similar to Isabelle ( https://isabelle.in.tum.de/ ). Example of Isabelle input: https://isabelle.in.tum.de/dist/library/HOL/HOL/HOL.html . Also, I am going to write converters between various languages. For example, between input for some existing PTS checker and my PTS checker. In short, I want to write lot of parsers and pretty-printers for various languages. And thus I need some parsing solution. The solution should have the following features: 1. The parsing should be divided into lexing and parsing. I. e. usual lex + yacc model. Parsing should be done using usual context-free grammars (CFGs). Left-recursive grammars should be supported (this leaves out parser combinator libraries). All languages I am going to deal with fit this model. I. e. I will deal with simple to parse languages, such as Pascal. Not complex ones, like C or C++. 2. Parsing should be deterministic. I. e. parser should check that CFG is unambiguous. Yes, I know that this task is impossible to do on Turing machine. But at very least some partial solution will go. For example, some algorithm, which will check that some reasonable set of CFGs is deterministic. Or even brute force up to some limit will go. (Yes, this will not give absolutely correct results, but this will go.) This is example of grammar for PTS in one of my checkers (start symbol is t0): t1000 = id t1000 = "(" t0")" t999 = t999 t1000 t3 = t4 "::" t3 t3 = "%" id "::" t0 "." t3 t0 = "!!" id "::" t0 "." t0 t1 = t2 "==>" t1 t0 = t1 t1 = t2 t2 = t3 t3 = t4 t4 = t999 t999 = t1000 If I remember correctly, this grammar is deterministic (checked using brute force up to a limit). I want solution which will verify that this grammar is deterministic. All stages of parsing should be proved as deterministic (i. e. scanner too). 3. Parsing should be reversible. I. e. pretty-printing should be supported, too. And the tool should guarantee that parsing and pretty-printing match. Now let me give more precise definition. Let's assume we have these functions: parse :: String -> Maybe X print :: X -> Maybe String As you can see, not every internal representation is printable. This is OK. For example, if internal representation contains variable names that happen to equal reserved words, then, of course, this is unprintable representation. The tool should guarantee that: a. Result of parsing should be printable, but printing not necessary should give same string. I. e. if "parse s == Just x", then "print x /= Nothing". (But not necessary "print x == Just s".) b. Parsing of result of printing should give same representation. I. e. if "print x == Just s", then "parse s == Just x" 4. Not only parsing should generate parse tree (i. e. exact representation of derivation), but also AST. AST differs from parse tree. For example, AST should not contain braces. I. e. "2 + (3 * 4)" and "2 + 3 * 4" should give same AST. And the tool should be able parse string to AST and pretty print AST back to string. 5. It should be possible to use CFG not known in compile time. Consider Isabelle language. Here is again example of Isabelle text: https://isabelle.in.tum.de/dist/library/HOL/HOL/HOL.html . As you can see the language is divided into inner language and outer language. Strings in inner language are quoted. Outer language can add productions to inner language. Inner language cannot change itself. "notation" and "translations" commands add productions to inner language. So inner language is not known beforehand, it is created dynamically. There is no need to dynamically create scanner, i. e. it should be possible to dynamically create parser (for inner language), but there is no such requirement for scanner. Also, parser will not change in the middle of parsing given string. Again: let's assume I write parser for my Isabelle analog. Scanner and parser for outer language is fixed. Scanner for inner language is fixed, too. But parser for inner language is not. I read input document and add productions to CFG of inner language on the fly. Every time I add production, resulting CFG should be checked for ambiguity. And when I find inner language string in input, I process it using just constructed parser for inner language. -- Points 2 and 3 are the most important in this list. If there is solution which contains them alone, this already will be very good. Now let me list considered solutions. * Usual combinator libraries (such as parsec) will not go. They don't work with left-recursive CFGs. They don't check grammars for ambiguities. They don't do reversible parsing. But they allow creating language on the fly, and this is good thing. * Happy and alex will not go. As well as I know Happy can prove unambiguity of some very simple grammars (i. e. for some set of simple grammars it will not report any conflicts and thus will prove they unambiguity). It seems this is LR(1) set. But, as well as I know, Happy will report conflicts on PTS grammar given above, i. e. Happy cannot prove its unambiguity. Also, Happy and Alex cannot pretty-print. And Happy and Alex don't allow supplying CFG on the fly. * Package "earley". Handle arbitrary CFGs, including left-recursive. This is good thing. It seems CFG can be supplied in runtime. This is good thing, too. Gives all parse trees, thus we can verify that count of parse trees equals to 1. This is good thing, too. Unfortunately, earley cannot verify CFS's unambiguity before supplying input. Also, earley doesn't support pretty-printing. * PEG libraries. Will not go, I want CFGs. * I searched on Hackage reversible parsing libraries. Unfortunately, none of them guarantee reversibility. I. e. it is very easy to fool these libraries and create parsers and printers not satisfying equations I gave above. Also, this libraries doesn't have other features I mentioned * http://augeas.net/ is very cool project. Unlike nearly everything I found in internet, Augeas provides guaranteed reversible parsing and pretty-printing (!!!!!). Unfortunately, set of supported target languages is very limited. Regular languages are supported. And some very limited set of CFGs is supported. For example, it is possible to construct parser for JSON. But parser for Pascal seems impossible. Augeas not designed for parsing programming languages. Only simple configuration languages like JSON, XML, etc. Mutually recursive nonterminals are not supported. Also, Augeas provides C API, not Haskell one. * https://www.brics.dk/xsugar.html is very good. It provides guaranteed reversible translation between arbitrary language and XML. And XSugar even verifies unambiguity of the CFG using some sophisticated algorithm. Unfortunately, this algorithm still cannot prove unambiguity of PTS grammar given above. Also, XSugar is not Haskell library. It is standalone Java app. So, I need to convert some language to XML, then load this XML to my Haskell program and parse. Also, there is similar lib https://www.brics.dk/Xact.html from same author, but it is for Java, not for Haskell. I was able to find only 2 projects, which do guaranteed reversible parsing: mentioned Augeas and XSugar/Xact. Unfortunately, both are not for Haskell. And both cannot prove unambiguity for my PTS grammar. So, please tell me about solution. Or give advice how to write one. Also, let me describe my experience with various algorithms for checking ambiguity of grammar. 1. Try to construct LR(1) table. If there is no conflicts, then the grammar is unambiguous. It seems this is algorithm used by bison and happy. Unfortunately it is too weak and cannot prove unambiguity of my PTS grammar. 2. Try to construct LR(k) table. This algorithm is stronger than LR(1). I was unable to find implementation of this algorithm in any language. I don't want to write such algorithm. 3. Schmitz's algorithm. http://www.lsv.fr/~schmitz/pub/expamb.pdf . Even stronger than LR(k). I downloaded his bison fork. Unfortunately this bison fork can prove unambiguity for same set of grammars original bison can (i. e. LR(1)). I. e. it seems Schmitz did not implemented his algorithm. I don't want to implement his algorithm either. 4. Horizontal and vertical ambiguity checking. https://www.brics.dk/grammar/kruse.pdf . This is algorithm used in XSugar. Unfortunately, it doesn't handle my PTS grammar. 5. Brute force up to some limit. Doesn't give unambiguity guarantee. But I like it, and I will use it if I don't find anything else. It is the only algorithm which can handle my PTS grammar (and give enough amount of guarantee), not counting LR(k) and Schmitz's algorithm (I was not able to find implementations of both). I will try to write tool I want, I will write about my progress to this list. == Askar Safin https://github.com/safinaskar

4 4

Re: [Haskell-cafe] upload file with ftp
by Kees Bleijenberg 06 Jan '21

06 Jan '21

Hi Brandon, The ftp-client I use (total commander) does not use passive mode. I changed the host to another server. And now I do not get an exception, no error messages, but nothing is uploaded. Unfortunately is ‘working in passive mode’ not so easy (at least not to me). After login I send the ‘pasv’ command and I get back a IP address and a port (I assume). Do I have to create a new connection with a handle to this new port for the stor command? I don’t know how to do that in network.ftp.client. A hint or better a working example would be nice. Kees Van: Brandon Allbery [mailto:allbery.b@gmail.com] Verzonden: dinsdag 5 januari 2021 13:49 Aan: Kees Bleijenberg <K.Bleijenberg(a)lijbrandt.nl> CC: haskell-cafe <haskell-cafe(a)haskell.org> Onderwerp: Re: [Haskell-cafe] FW: upload file with ftp At a guess, you're using a modern FTP client that defaults to passive mode for compatibility with firewalls, and you'll need to check the docs to see how to do passive mode with Network.Client.FTP. On Tue, Jan 5, 2021 at 7:24 AM Kees Bleijenberg <K.Bleijenberg(a)lijbrandt.nl <mailto:K.Bleijenberg@lijbrandt.nl> > wrote: I want to upload a file with ftp using library Network.FTP.Client. The OS is Windows 64 and ghc version is 8.6.4. This is the code: import System.FilePath.Windows import Network.FTP.Client import qualified Data.ByteString as B .... testFtp :: IO (Either String ()) testFtp = do let host = "copecco" -- this is from my hosts file username = **** pwd = **** ftpDir = "registratie" fileToSend = "globals.pas" -- a test text file putStrLn $ "Connect to " ++ host withFTP host 21 $ \h ftpResponse -> do print ftpResponse if frStatus ftpResponse == Success then do putStrLn "Connected" loginResp <- login h username pwd print loginResp if frStatus loginResp == Success then do putStrLn $ "Change directory to " ++ ftpDir cwdResp <- cwd h ftpDir print cwdResp if frStatus cwdResp == Success then do putStrLn "Read file from disk" let ftpFn = takeFileName fileToSend fileContents <- B.readFile fileToSend putStrLn $ "File size: " ++ show (B.length fileContents) ++ " bytes" stor h ftpFn fileContents TI return $ Right () else return $ Left $ "Ftp error cwd. Code: " ++ show (frCode ftpResponse) else return $ Left $ "Ftp error login. Code: " ++ show (frCode ftpResponse) else return $ Left $ "Connect to host " ++ host ++ " failed. Code: " ++ show (frCode ftpResponse) This is the response: Connect to copecco 220 (vsFTPd 3.0.2) Connected 230 Login successful. Change directory to registratie 250 Directory successfully changed. Read file File size: 27015 bytes *** Exception: Network.Socket.connect: <socket: 444>: failed (Connection timed out (WSAETIMEDOUT)) Everything works fine until the stor commmand. When I upload the same file with another ftp client program everything works (no permission problems). What is wrong and how do I get the result codes for the stor command? Kees _______________________________________________ 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. -- brandon s allbery kf8nh allbery.b(a)gmail.com <mailto:allbery.b@gmail.com>

3 4

command substitution in ghci?
by Johannes Waldmann 06 Jan '21

06 Jan '21

In a ghci session, I have an IO action that returns a file name, and then I want to :script that file. (The action could also be made to return the contents.) Cf. Bash has $(foo) to allow the output of a command to replace the command itself. See Bash manual 3.5.4 "Command Substitution" - $(command) and $(< file). We do have a work-around, since this is being called from an elisp program. This is just about a micro-optimisation of not calling ghci twice. https://github.com/tidalcycles/Tidal/issues/743 And the whole thing is a work-around for ghc and ghc-pkg not agreeing on the use of environment files (I think) - J.

1 0

FW: upload file with ftp
by Kees Bleijenberg 05 Jan '21

05 Jan '21

I want to upload a file with ftp using library Network.FTP.Client. The OS is Windows 64 and ghc version is 8.6.4. This is the code: import System.FilePath.Windows import Network.FTP.Client import qualified Data.ByteString as B .... testFtp :: IO (Either String ()) testFtp = do let host = "copecco" -- this is from my hosts file username = **** pwd = **** ftpDir = "registratie" fileToSend = "globals.pas" -- a test text file putStrLn $ "Connect to " ++ host withFTP host 21 $ \h ftpResponse -> do print ftpResponse if frStatus ftpResponse == Success then do putStrLn "Connected" loginResp <- login h username pwd print loginResp if frStatus loginResp == Success then do putStrLn $ "Change directory to " ++ ftpDir cwdResp <- cwd h ftpDir print cwdResp if frStatus cwdResp == Success then do putStrLn "Read file from disk" let ftpFn = takeFileName fileToSend fileContents <- B.readFile fileToSend putStrLn $ "File size: " ++ show (B.length fileContents) ++ " bytes" stor h ftpFn fileContents TI return $ Right () else return $ Left $ "Ftp error cwd. Code: " ++ show (frCode ftpResponse) else return $ Left $ "Ftp error login. Code: " ++ show (frCode ftpResponse) else return $ Left $ "Connect to host " ++ host ++ " failed. Code: " ++ show (frCode ftpResponse) This is the response: Connect to copecco 220 (vsFTPd 3.0.2) Connected 230 Login successful. Change directory to registratie 250 Directory successfully changed. Read file File size: 27015 bytes *** Exception: Network.Socket.connect: <socket: 444>: failed (Connection timed out (WSAETIMEDOUT)) Everything works fine until the stor commmand. When I upload the same file with another ftp client program everything works (no permission problems). What is wrong and how do I get the result codes for the stor command? Kees

2 1

Nominations close Jan 11th for the Haskell Foundation Board
by Simon Peyton Jones 05 Jan '21

05 Jan '21

Friends Happy new year! The closing date for self-nominations for membership of the Board of the Haskell Foundation<https://haskell.foundation/> is in just under a week: Monday January 11th 2021 The Haskell Foundation is a new non-profit organisation that seeks to articulate the benefits of functional programming to a broader audience, to erase barriers to entry, and to support Haskell as a solidly reliable basis for mission-critical applications. The Board provides the strategic leadership for the Foundation, including its goals, governance, finances, and staff. Membership of the Board is a key leadership role, not an honorary appointment. The Call for Nominations<https://haskell.foundation/board-nominations/> gives more details. Please do consider nominating yourself, or encouraging a suitable (but perhaps modest) colleague to do so. The HF needs a strong Board, and that means strong nominations. Thanks! Please do forward this message on social media or elsewhere. Simon Peyton Jones

1 0

[TFPIE'21] Third and Final Call For Papers: Trends in Functional Programming *in Education* 2021, 16 February 2021 (with Lambda Days 2021 & TFP 2021)
by Peter Achten 04 Jan '21

04 Jan '21

---------------------------------------------- TFPIE 2021 3rd and Final Call for papers ---------------------------------------------- *************************************************************** - Submission deadline: January 11 2021, Anywhere on Earth. *************************************************************** https://wiki.tfpie.science.ru.nl/TFPIE2021#TFPIE_2021 (February 16 2021, co-organized with TFP 2021 and Lambda Days 2021) Because of the covid pandemic, the events are online this year. The goal of the International Workshops on Trends in Functional Programming in Education is to gather researchers, professors, teachers, and all professionals that use or are interested in the use of functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas, and work in progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. TFPIE 2021 welcomes submissions in the above mentioned areas. This year many teaching programmes have had to make a rapid transition to online teaching, and we explicitly solicit papers that explore this area of teaching functional programming. Topics of interest include, but are not limited to: - FP and beginning CS students - FP and Computational Thinking - FP and Artificial Intelligence - FP in Robotics - FP and Music - Advanced FP for undergraduates - FP in graduate education - Engaging students in research using FP - FP in Programming Languages - FP in the high school curriculum - FP as a stepping stone to other CS topics - FP and Philosophy - The pedagogy of teaching FP - FP and e-learning: MOOCs, automated assessment etc. - Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. On top of the lecture itself, the presentation can also provide commentary on the lecture. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 20 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2021 After the workshop, presenters are invited to submit (a revised version of) their article for review. The PC will select the best articles for publication in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Dates - Submission deadline: January 11 2021, Anywhere on Earth. - Notification: January 15 2021 - Workshop: February 16 2021 - Submission for formal review: April 20 2021, Anywhere on Earth. - Notification of full article: June 7 2021 - Camera ready: July 1st 2021 Program Committee - Peter Achten, Radboud University, Netherlands (chair) - Edwin Brady, University of St Andrews, UK - Laura Castro, Universidade da Coruña, Spain - Stephen Chang, University of Massachusetts Boston, USA - Youyou Cong, Tokyo Institute of Technology, Japan - Matthew Flatt, University of Utah, USA - Seth Fogarty, Trinity University, USA - Alex Gerdes, University of Gothenburg, Sweden - Gabriele Keller, Utrecht University, Netherlands - Prabhakar Ragde, University of Waterloo, Canada - Melinda Tóth, Eötvös Loránd University, Budapest, Hungary Registration TFPIE is part of Lambda Days. Please visit the Lambda Days 2021 pages when registration information becomes available. Only papers that have been presented at TFPIE may be submitted to the post-reviewing process. Information on Lambda Days is available at https://www.lambdadays.org/lambdadays2021 Information on TFP is available at http://tfp2021.org

1 0

Re: [Haskell-cafe] How to do reversible parsing?
by Michal J Gajda 03 Jan '21

03 Jan '21

Hi Askar, > Hi. How to do deterministic reversible parsing in Haskell? Please, point me to some libs or tools. > Or give some advice on how to write such lib or tool. (Also, I am interested in solutions for C or C++.) > > Now let me explain my task in detail. I liked the bidirectional applicatives and monads described in here: 1. Composing bidirectional programs monadically (with appendices) - Li-yao Xia, Dominic Orchard, Meng Wang https://arxiv.org/abs/1902.06950 You can use it for both bidirectional parsing/pretty pretting and type inference/type checking. 2. BiGuL is a bit more complicated: https://bitbucket.org/prl_tokyo/bigul/src/master/ -- Cheers Michał

1 0

[ANN] fp-ieee v0.1
by ARATA Mizuki 03 Jan '21

03 Jan '21

Hi all, I'd like to announce the first release of fp-ieee. https://hackage.haskell.org/package/fp-ieee This library aims to provide IEEE 754-2019 compliant operations, including * fusedMultiplyAdd * correctly-rounding versions of fromInteger (GHC's fromInteger for Float and Double do not round correctly; see https://gitlab.haskell.org/ghc/ghc/-/issues/17231) * realFloatToFrac: an alternative of realToFrac with well-defined semantics. Other notes: * Most of the functions are generic, and any RealFloat instance can be used. However, manipulation of NaN's sign and payload requires an additional constraint (RealFloatNaN, provided by this library). * Access to floating-point environment is not provided. If you want to control rounding direction, look at my another library: https://hackage.haskell.org/package/rounded-hw * Decimal-specific operations (like quantize, quantum) are not provided, and the preferred exponent is not honored. * Use of FFI can be disabled via a package flag (maybe useful when using non-native targets). Mizuki

2 3

ghc/cabal problems - mystery?
by Gregory Guthrie 31 Dec '20

31 Dec '20

I reported several odd and inconsistent results that I can't understand, and after some further trials, a few more data points, but still confused. A directory of files, cabal build runs fine, then trying to execute; I get three different results; Linking D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe ... Seems fine. Then; from that same shell (PS) in the same directory - >From cabal run: Fails PS D:\CS\Courses\long path\All Solutions> cabal run Up to date D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl: createProcess: invalid argument (Invalid argument) >From using the explicit path: Fails PS D:\CS\Courses\long path\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detailAt line:1 char:1 + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~. At line:1 char:1 + dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed >From going to the dist folder: runs fine. PS D:\CS\Courses\long path\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl PS D:\CS\Courses\long path\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl> apl.exe "APL: Examples and labs" I get a few other errors & results sometimes; copy the full directory to somewhere else, "cabal clean", And it won't build, "no target specified", even though the entire folder is identical. Again; every time just copying the entire directory, no editing of any files, just running cabal as above. Any hints or ideas why I am getting these issues & errors? GHC 8.10.2 Cabal 3.2.0.0 (Windows 10) ------------------------------------------------------------------------ PS: One more... I (again) copied the entire directory to another place and retested, in that case "cabal run" did run, but gave results from a different file in the directory (multiple tests there, only one run from Main.hs, same .cabal file), and can run it by explicit path or "cabal run". All results should be "DSem_imp", one is from a different file, "DSem_impc" ?? Certainly looks like they should all be running the same apl.exe. ?? Output"" PS G:\Testing\All Solutions> cabal clean PS G:\Testing\All Solutions> cabal run Resolving dependencies... Build profile: -w ghc-8.10.2 -O1 In order, the following will be built (use -v for more details): - apl-0.0.1 (exe:apl) (first run) Configuring apl-0.0.1... Preprocessing executable 'apl' for apl-0.0.1.. Building executable 'apl' for apl-0.0.1.. ... Linking G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe ... "APL: Examples and labs" "======================" "------ APL:: DSem_imp" PS G:\Testing\All Solutions> dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl\apl.exe "APL: Examples and labs" "======================" "------ APL:: DSem_imp" PS G:\Testing\All Solutions> cd dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> ls Directory: G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 12/30/2020 12:18 PM apl-tmp d----- 12/30/2020 12:17 PM autogen -a---- 12/30/2020 12:18 PM 11230184 apl.exe PS G:\Testing\All Solutions\dist-newstyle\build\x86_64-windows\ghc-8.10.2\apl-0.0.1\build\apl> apl.exe "APL: Examples and labs" "======================" "------ APL:: DSem_impc" Gregory Guthrie Maharishi International University ----------------------------------------------------------------

2 3

cabal errors
by Gregory Guthrie 28 Dec '20

28 Dec '20

I'm having some issues with Cabal , wonder if they are known issues. 1) I had a previously working installation of files, hadn't used them for some time, did Haskell upgrades (chocolatey), and tried to recompile. I got a weird error on running the build - Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detailAt line:1 char:1 + ./apl + ~~~~~. At line:1 char:1 + ./apl + ~~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed Chasing this all around - no solutions so I started over, in a new location, adding one file at a time. Worked fine. 2) So I then has a current working build in some top level xTest temporary directory. (Just a direct copy of all the files, and "cabal v2-build") 3) So I then just copied all the source files back to a desired installation place, with a longer path name. 4) But there it fails to build: PS D:\CS\Courses\long path\Solns\All Solutions> cabal v2-install Wrote tarball sdist to D:\CS\Courses\long path\Solns\All Solutions\dist-newstyle\sdist\apl-0.0.1.tar.gz Resolving dependencies... Build profile: -w ghc-8.10.1 -O1 In order, the following will be built (use -v for more details): - apl-0.0.1 (exe:apl) (requires build) cabal.exe: Failed to unpack apl-0.0.1. The exception was: dieVerbatim: user error (cabal.exe: Package .cabal file not found in the tarball: C:\Users\guthrie\AppData\Local\Temp\cabal-install.-2584\dist-newstyle\tmp\src-2584\apl-0.0.1\apl.cabal) 5) Just copying (again) the same folder of files which is failing to a top level new folder (yTest), deleting the dist-newstyle folder, And running "cabal v2-buld" again, all works fine, no errors, executable built. Three directories, all with the same files - one fails. ?? The only difference I can see is the long path name with blanks in it - is that an issue? Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

1 1

Re: [Haskell-cafe] [Ann] group-theory
by Olaf Klinke 26 Dec '20

26 Dec '20

Koji Miyazato wrote: > > You can use `MonoidNull`. from monoid-subclasses to avoid an `Eq` > constraint. > > For groups, there is no difference between `MonoidNull` and `Eq`, as > you can define `x == y` be > `null (x <> inv y)`. There are monoids which `==` is not even > decidable but `null` is (e.g. context-free grammars > with equality defined by the language it defines), but such monoid > necessarily has no `Group` instance. A beautiful example of topological groups: Their topology is completely determined by the neighbourhoods of the identity element. If the identity element is isolated, the entire group is discrete. Olaf

1 0

[Ann] group-theory
by Emily Pillmore 26 Dec '20

26 Dec '20

Hello all, I am pleased to announce the release of the group-theory ( https://hackage.haskell.org/package/group-theory ) package: a package aimed at implementing the theory of finite groups in a reasonably ergonomic, well-documented, and featureful way. It's hardly finished, but my co-maintainer, Reed Mullanix (@totbwf) and I thought this was a good mvp with which we could announce. Contributions are very welcome, and I hope everyone enjoys. Cheers, Emily Pillmore

7 12

Haskell-language-server is looking for a logo
by Alan & Kim Zimmerman 24 Dec '20

24 Dec '20

Hi all, The haskell language server is coming up for its first birthday in January. To celebrate we would like to collectively choose a logo. So if you have a creative streak and would like to donate a lasting contribution to the project, please submit for consideration at [1]. We will aim to close the judging on 25 Jan 2021, being the anniversary of the Bristol Hackathon[2] where HLS was born. Alan [1] https://github.com/haskell/haskell-language-server/issues/694 [2] https://mpickering.github.io/bristol2020.html

5 5

Supporting Haskell.org
by Rebecca Skinner 23 Dec '20

23 Dec '20

Hi everyone. Apologies for the second email here. I originally sent this message with an incorrect subject, and I wanted to re-post here with a correct subject for visibility. This has been an eventful year for many of us, and haskell.org is no different. This year we've continued to support a significant part of the Haskell community infrastructure- including haskell.org, Hackage, Hoogle, and GHC build infrastructure. We're able to do this thanks to the support of the Haskell community. In addition to our ongoing work maintaining Haskell community infrastructure, we once again participated in the Google Summer of Code this year, supporting 12 projects. You can read more about the projects here: https://summer.haskell.org/news/2020-10-12-final-results.html As many of you are likely aware, this year also saw some of our community successfully launch a new initiative, the Haskell Foundation. We are thrilled for the Haskell Foundation and congratulate them on their successful launch. Haskell.org is an independent organization, and while we welcome any opportunities to collaborate with the Haskell Foundation, we will continue to pursue our mission of managing and supporting Haskell community infrastructure. If you would like to support Haskell.org in our mission, you can donate via several method, including PayPay and check: https://www.haskell.org/donations/ Haskell.org can also accept donations through employers via Benevity using the unique ID 475236502. Haskell.org is a 501(c)(3) non-profit, so donations may be tax-deductible in your jurisdiction. Another way to help haskell.org is to serve on the committee. We have three positions opening in 2021, and our call for nominations is open through Jan 7th 2021. Please email the committee at committee(a)haskell.org if you would like to nominate yourself or someone else for a position. We look forward to continuing this work with your support in 2021 as well as exploring new projects to improve the Haskell community infrastructure. Best wishes, Rebecca Skinner on behalf of the haskell.org committee.

1 0

Supporting The Haskell Foundation
by Rebecca Skinner 23 Dec '20

23 Dec '20

This has been an eventful year for many of us, and haskell.org is no different. This year we've continued to support a significant part of the Haskell community infrastructure- including haskell.org, Hackage, Hoogle, and GHC build infrastructure. We're able to do this thanks to the support of the Haskell community. In addition to our ongoing work maintaining Haskell community infrastructure, we once again participated in the Google Summer of Code this year, supporting 12 projects. You can read more about the projects here: https://summer.haskell.org/news/2020-10-12-final-results.html As many of you are likely aware, this year also saw some of our community successfully launch a new initiative, the Haskell Foundation. We are thrilled for the Haskell Foundation and congratulate them on their successful launch. Haskell.org is an independent organization, and while we welcome any opportunities to collaborate with the Haskell Foundation, we will continue to pursue our mission of managing and supporting Haskell community infrastructure. If you would like to support Haskell.org in our mission, you can donate via several method, including PayPay and check: https://www.haskell.org/donations/ Haskell.org can also accept donations through employers via Benevity using the unique ID 475236502. Haskell.org is a 501(c)(3) non-profit, so donations may be tax-deductible in your jurisdiction. Another way to help haskell.org is to serve on the committee. We have three positions opening in 2021, and our call for nominations is open through Jan 7th 2021. Please email the committee at committee(a)haskell.org if you would like to nominate yourself or someone else for a position. We look forward to continuing this work with your support in 2021 as well as exploring new projects to improve the Haskell community infrastructure. Best wishes, Rebecca Skinner on behalf of the haskell.org committee.

1 1

cabal build fails: sidebyside
by Gregory Guthrie 22 Dec '20

22 Dec '20

I have a fairly simple Haskell program which I build with cabal, which ends up seemingly successful with an executable (apl.exe). (but what a path(!): . \dist-newstyle\build\x86_64-windows\ghc-8.10.1\apl-0.0.1\build\apl\apl.exe Running that gives an error: Program 'apl.exe' failed to run: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detailAt line:1 char:1 + ./apl + ~~~~~. At line:1 char:1 + ./apl + ~~~~~ + CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException + FullyQualifiedErrorId : NativeCommandFailed Looking in the Windows event viewer, it reports: Activation context generation failed for "...\apl.exe". Error in manifest or policy file "...apl.exe" on line 2. Invalid Xml syntax. Sxstrace did not seem to give any additional information: Begin Activation Context Generation. Input Parameter: Flags = 0 ProcessorArchitecture = AMD64 CultureFallBacks = en-US;en ManifestPath = D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\apl.exe AssemblyDirectory = D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\ Application Config File = ----------------- INFO: Parsing Manifest File D:\CS\Courses\CS505 -APL\Labs & Hmwks\Dsem Labs -Haskell Solns\dist-newstyle\build\x86_64-windows\ghc-8.10.1\APL-0.0.1\build\APL\apl.exe. INFO: Manifest Definition Identity is (null). ERROR: Line 2: XML Syntax error. ERROR: Activation Context generation failed. End Activation Context Generation. Online some posts suggest installing a current VC_redist - I did that, no relief. Any suggestions on what is causing this, and a fix? Running GCH: 8.10.1 Cabal: 3.2.0.0 Windows 10 Dr. Gregory Guthrie

1 0