- Haskell-Cafe - Haskell.org

Call for Talks: Haskell Implementors' Workshop
by Ningning Xie 22 Mar '21

22 Mar '21

Call for Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2021. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnning at hku.hk>

1 0

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

22 Mar '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

ANN unicode-general-category-0.1.0.0
by Javran Cheng 22 Mar '21

22 Mar '21

Hi Cafe, I'm happy to announce the release of a new package: unicode-general-category. This package provides the same set of functions related to Unicode general category found in Data.Char, but uses information from Unicode 13.0.0 - in addition a set of tools are offered to turn any modern UnicodeData.txt into such a set of functions. I wrote this as a by-product of my recent adventure into parsing Java (it follows Unicode 13, but Data.Char is dependent on GHC versions), but hope this can also be helpful to others in some way. https://hackage.haskell.org/package/unicode-general-category https://github.com/Javran/unicode-general-category Cheers, Javran (Fang) Cheng

1 0

Re: [Haskell-cafe] Global Package Install
by Johannes Waldmann 21 Mar '21

21 Mar '21

Hi. Interesting discussion. Thanks for data points on using cabal-install for the classroom. > the work-around described in the second linked cabal issue (#6515), > namely setting `store-dir` and `remote-repo-cache` > to a global read-only location, works very well in practice. Good to know. I will look into it. This "setting" has to be done by each student (once)? Well, they have to create/change other configurations as well (e.g., put proper PATH in .bashrc) so it's probably OK. And, students can then not cabal-install extra private packages? (With global package installs, they could. But perhaps it's better that they cannot, for all the reasons mentioned.) > .. helping students when we were clearly using the same codebase this is solved by `stack --resolver=<...>` but that eats space and requires another extra tool (stack) besides ghc(i). > I saw no reason to try an alternative version [to the global install] Well I did, and that reason was "cabal hell", where "global hell" is the worst, as it regularly requires a fresh ghc install. So for my own work of course I do use per-user install, and other forms of isolation. Best regards, Johannes.

1 0

Re: [Haskell-cafe] Global Package Install
by Johannes Waldmann 21 Mar '21

21 Mar '21

> .. a few people mention that they prefer the > "global package database" style. I'd like to improve my understanding > of why people prefer that style. Teaching. Reduce storage, and save students the extra work and distraction. https://github.com/haskell/cabal/issues/7172 same question, with discussion of possible work-around with "shared local" database: https://github.com/haskell/cabal/issues/6515 I will need this in two week's time .. - J.W.

3 2

WST 2021 - Call for Papers
by Samir Genaim 21 Mar '21

21 Mar '21

====================================================================== WST 2021 - Call for Papers 17th International Workshop on Termination http://costa.fdi.ucm.es/wst2021 July 16, 2021, Pittsburgh, PA, United States Co-located with CADE-28 *** The Workshop will be Virtual *** ====================================================================== The Workshop on Termination (WST) traditionally brings together, in an informal setting, researchers interested in all aspects of termination, whether this interest be practical or theoretical, primary or derived. The workshop also provides a ground for cross-fertilization of ideas from the different communities interested in termination (e.g., working on computational mechanisms, programming languages, software engineering, constraint solving, etc.). The friendly atmosphere enables fruitful exchanges leading to joint research and subsequent publications. IMPORTANT DATES: * submission deadline: April 25, 2021 * notification: May 30, 2021 * final version due: June 13, 2021 * workshop: July 16, 2021 INVITED SPEAKERS: TBA TOPICS: The 17th International Workshop on Termination welcomes contributions on all aspects of termination. In particular, papers investigating applications of termination (for example in complexity analysis, program analysis and transformation, theorem proving, program correctness, modeling computational systems, etc.) are very welcome. Topics of interest include (but are not limited to): * abstraction methods in termination analysis * certification of termination and complexity proofs * challenging termination problems * comparison and classification of termination methods * complexity analysis in any domain * implementation of termination methods * non-termination analysis and loop detection * normalization and infinitary normalization * operational termination of logic-based systems * ordinal notation and subrecursive hierarchies * SAT, SMT, and constraint solving for (non-)termination analysis * scalability and modularity of termination methods * termination analysis in any domain (lambda calculus, declarative programming, rewriting, transition systems, etc.) * well-founded relations and well-quasi-orders SUBMISSION GUIDELINES: Submissions are short papers/extended abstracts which should not exceed 5 pages. There will be no formal reviewing. In particular, we welcome short versions of recently published articles and papers submitted elsewhere. The program committee checks relevance and provides additional feedback for each submission. The accepted papers will be made available electronically before the workshop. Papers should be submitted electronically via the submission page: https://easychair.org/conferences/?conf=wst2021 Please, use LaTeX and the LIPIcs style file http://drops.dagstuhl.de/styles/lipics/lipics-authors.tgz to prepare your submission. PROGRAM COMMITTEE: * Martin Avanzini - INRIA Sophia, Antipolis * Carsten Fuhs - Birkbeck, U. of London * Samir Genaim (chair) - U. Complutense de Madrid * Jürgen Giesl - RWTH Aachen * Matthias Heizmann - U. of Freiburg * Cynthia Kop - Radboud U. Nijmegen * Salvador Lucas - U. Politècnica de València * Étienne Payet - U. de La Réunion * Albert Rubio - U. Complutense de Madrid * René Thiemann - U. of Innsbruck

1 0

strange cabal error
by Ben Franksen 18 Mar '21

18 Mar '21

Any idea what I am running into here? ben@home[5]:.../softIOC/home>cabal build Resolving dependencies... TODO: add support for multiple packages in a directory CallStack (from HasCallStack): error, called at ./Distribution/Client/ProjectOrchestration.hs:548:9 in main:Distribution.Client.ProjectOrchestration This appears immediately after I issued a (successful) ben@home[5]:.../softIOC/home>cabal init --minimal --package-name test Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

1 1

Some Alex beginner questions regarding parsing Java
by Javran Cheng 18 Mar '21

18 Mar '21

Hi Cafe! Firstly, sorry for spamming if you already see this on Stack Overflow, I do feel this is too much for a single SO question. I'm recently playing with Alex + Happy to try parsing Java (for now I'm only working on the lexer / Alex, so whenever you see "parse" below, that means tokenize). My reference is Java SE 15 Spec, the chapter of interest is Chapter 3. Lexical Structure <https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html> (side note: my timing is a bit interesting as I just realized as of writing this, Java SE 16 spec is out just few days ago, so I might switch to that) and now that I've get my hand dirty a bit, I have few questions and hope if someone can shed some light on them: 1. For now I'm using "monad-bytestring" wrapper for performance, but now I think maybe String-based wrapper is more appropriate, for it allows me to follow 1. and 2. in "3.2. Lexical Translations" properly before passing the input to Alex - namely I can pre-process input stream to (1) do Unicode escaping to turn the raw byte flow into a flow of Chars (2) I can normalize line terminators into just \n. But: 1. Are those two passes (Unicode escape and line terminator normalization) possible within Alex framework? 2. Is there any way that I can stick with a memory-compact string representation? (not sure why Alex doesn't provide any Text-based wrapper, as it did mention in its doc that it internally works on UTF-8 encoded byte sequence) I could probably consider to not use any wrapper, as GHC and Agda did, but that's sort of an undocumented territory so I'm hesitated to do so. 2. The other trouble I have regarding "3.2. Lexical Translations" is the special rules applied to ">"s: "... There is one exception: if lexical translation occurs in a type context (§4.11) ..." - but how in the world am I going to do this? I mean the lexical analysis is not even done how am I going to tell whether it's a type context (and §4.11 is quite long that I won't even try to read it, unless forced)? Maybe I can just tokenize every ">" as an individual operatior, as if ">>", ">>=", ">>>", and ">>>=" don't exist and worry about that later, but that doesn't sound right to me. 3. I realize there's a need for "irrecoverable failure": I have a test case with octal literal "012389", which is supposed to fail, but Alex happily tokenized that into [octal "0123", decimal "89"] - for now my workaround is for every number literal to check whether previous char is a digit and fail if it is indeed so, but I feel this is like ducktaping on a flawed approach and at some point it will fail on some edge cases. an ideal fix IMO would be to have some notion of irrecoverable failure - failing to parse a literal at full should be irrecoverable rather than trying to parse most of it and move on. In addition, as Java spec requires that if a numeric literal doesn't fit in the intended type, it's a compilation error - which can also be encoded as an irrecoverable failure as well. I'm not sure how to do that in Alex though, I can see few ways: 1. encode irrecoverable failure by setting to a special startcode, which does not provide anyway to go back to startcode 0 - so an irrecoverable failure sets that special startcode, and at the start of every action, it checks whether startcode is the special "failure" startcode and fail accordingly 2. this is similar to startcode, but use a wrapper that supports userstate. 3. maybe this is another case that not using a wrapper would give me more control, but I don't have a concrete idea regarding this alternative. Any thoughts on this is appreciated. Thanks! Javran (Fang) Cheng

2 2

Re: [Haskell-cafe] shorter error messages
by Richard Eisenberg 17 Mar '21

17 Mar '21

In the short-term: I'll take option 3. We've already changed some of the datatypes around there, and the new output reflects the new structure. I did poke around a bit (https://gitlab.haskell.org/ghc/ghc/-/issues/19278) asking if anyone relied on the existing structure, and we were told just to update as we saw fit. In the longer-term: Option 1. The JSON feature is, essentially, undesigned. It just happened. There is no real specification or supported story for what tools are likely to consume the data. After this overhaul, it will be easy to imagine arbitrarily structured and informative JSON output, and so I imagine we'll start a conversation with consumers (i.e. IDEs and similar tools) to design an advertised interface. This interface will need to be somewhat unstable in perpetuity, as GHC improves errors, adds new ones, etc. But my hope is that the stated design encompasses this need for change and specifies what will and will not change over time. Maybe even there will be a way to query GHC for its JSON schema? Not sure. An important detail is that the flag for JSON output is -ddump-json, starting with a `d`; this means it's in the "debugging GHC" section of the manual. I hope that changes someday (where "hope" implies that I will actively support efforts at doing so). Richard > On Mar 16, 2021, at 6:01 PM, Sebastiaan Joosten <sjcjoosten(a)gmail.com> wrote: > > Hi Richard, > > this raises a question about the upcoming overhaul: is the JSON dump format following -ddump-json most likely to: > 1. change a lot (complete overhaul is likely and/or feature might disappear - say because all datatypes will be changed and the JSON is just some 'deriving Generic' ToJSON dump with default parameters) > 2. stay the same mostly (if/wherever it changes, it is either a bug or deliberate feature) > 3. change in minor ways (stability is not considered important in the overhaul but there are no reasons to believe this part of the code will be affected much) > ? > > What would your guess be? > > Sebastiaan > > PS: feel free to reply to cafe if that seems fitting – my mails there get rejected (issue on my end) > >> On 16 Mar 2021, at 14:07, Richard Eisenberg <rae(a)richarde.dev> wrote: >> >> There is no "official" way to accommodate this reasonable request. The ideas up-thread are good ones. >> >> I want to pipe in that we're currently going through an internal overhaul of error-message handling that will make such a request much easier to contemplate in the future. This is active work going on right now. So there is hope, possibly for 9.4. Of course, once the internal overhaul is done, we'll need to design any features that actually change the output -- the overhaul just makes it easy to implement such features (which would be very difficult at the moment). >> >> Richard >> >>> On Mar 16, 2021, at 12:56 PM, Jaro Reinders <jaro.reinders(a)gmail.com> wrote: >>> >>> On 16-03-2021 17:40, Tom Smeding wrote: >>>> In any case, the haskell language server just uses GHC internally, so it just shortens the GHC message. But then I believe the same result could be accomplished by some simple text manipulation on GHC's normal output. >>> >>> In fact, you can use -ddump-json to get JSON error messages. I should be easy to convert that to any form you like. >>> >>> But there is no clear specification of that output: >>> https://gitlab.haskell.org/ghc/ghc/-/issues/19278 >>> >>> And I also want to point out that there is a big open issue for better error messages: >>> https://gitlab.haskell.org/ghc/ghc/-/issues/8809 >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >

1 0

shorter error messages
by Ben Franksen 17 Mar '21

17 Mar '21

Is there a way to tell ghc to print errors, especially type errors in a more concise way? Ideally one or two lines of text? I hate it when I have to scroll several pages of text just to see the next/previous error location. Cheers Ben -- Niemand hat das Recht zu gehorchen. -- Hannah Arendt

7 9