April 2021 - Haskell-Cafe

GLR parser for Haskell?
by Benjamin Redelings 21 Apr '21

21 Apr '21

Hi, I've been looking at the Haskell parser in ghc/compiler/GHC/Parser.y. It relies on post-processing pretty heavily, both to determine the type of parsed expressions (i.e. is "(x,y)" a pattern or expression?) and to reject invalid syntax (i.e. field declarations are parsed as a type, but this is rejected during postprocessing I think, except in constructor declarations). This makes the grammar rather hard to read. To quote [1]: > Insteadof describingthe languageto be parsed,thegrammardescribes > theprocessused to parseit; it'smore like a hand-crafted parsing > program,butcrammed into Backus-Naur Form. Does anybody know if there is another version of the parser generator uses grammar rules that are closer to the grammar rules in the 2010 report? Maybe a GLR grammar? Also, I see that Happy is able to generate GLR parsers. I'm curious if GLR parsers aren't being used just because they are slow, or if there is some other reason they are hard to use. I am not an expert on parsing or grammars, so any insight would be appreciated. Thanks! -BenRI [1] https://escholarship.org/uc/item/8559j464

5 6

Bx 2021 - FINAL CALL FOR PAPERS
by Meng Wang 21 Apr '21

21 Apr '21

Dear Haskellers, Lenses is Bx and our own Edward Kmett will be giving the keynote! Please consider submitting. Best regards, Meng Bx 2021 - FINAL CALL FOR PAPERS ********************************************************************************** 9th International Workshop on Bidirectional Transformations (Bx 2021) as part of the STAF conference (June 21, 2021) running virtually, Western Norway University of Applied Sciences, Bergen, Norway http://bx-community.wikidot.com/bx2021:home ********************************************************************************** * Important dates: * Abstract submission: April 27, 2021 * Paper Submission: May 4, 2021 ********************************************************************************** OVERVIEW ========================================= Bidirectional transformations (bx) are a mechanism for maintaining the consistency between two or more related (and heterogeneous) sources of information (i.e., relational databases, software models and code, or any other artefacts following standard or domain-specific formats). The strongest argument in favour of bx is its ability to provide a synchronization mechanism that is guaranteed to be correct by construction. Bx has been attracting a wide range of research areas and communities, with prominent presence at top conferences in several different fields (namely databases, programming languages, software engineering, and graph transformation). Nowadays, the fast-growing complexity of software- or data- intensive systems has forced the industry and the academy to use and investigate different development techniques to manage the many different aspects of the systems. Researchers are actively investigating the use of bidirectional approaches to tackle a diverse set of challenges with various applications including model-driven software development, visualization with direct manipulation, big data, databases, domain-specific languages, serializers, and data transformation, integration and exchange. Bx 2021 is a dedicated venue for bx in all relevant fields and is part of a workshop series that was created in order to promote cross-disciplinary research and awareness in the area. As such, since its beginning in 2012, the workshop has rotated between venues in different fields. KEYNOTE ========================================= We are happy to announce our keynote speaker: Edward Kmett. TOPICS ========================================= The aim of the workshop is to bring together researchers and practitioners, established and new, interested in bx from different perspectives, including but not limited to: * bidirectional programming languages and frameworks * software development with bx * data and model synchronization * view updating * inter-model consistency analysis and repair * data/schema (or model/metamodel) co-evolution * coupled software/model transformations * inversion of transformations and data exchange mappings * domain-specific languages for bx * analysis and classification of requirements for bx * bridging the gap between formal concepts and application scenarios * analysis of efficiency of transformation algorithms and benchmarks * model-driven and model-based approaches * survey and comparison of bx technologies * case studies and tool support CATEGORIES OF SUBMISSIONS ========================================= Five categories of submissions are considered: * Full Research Papers (13-15 pages) - in-depth presentations of novel concepts and results - applications of bx to new domains - survey papers providing novel comparisons between existing bx technologies and approaches, case studies * Tool Papers (7-8 pages) - guideline papers presenting best practices for employing a specific bx approach (with a specific tool) - presentation of new tools or substantial improvements to existing ones - qualitative and/or quantitative comparisons of applying different bx approaches and tools * Experience Report (7-8 pages) - sharing experiences and lessons learned with bx tools/frameworks/languages - how bx is used in (research/industrial/educational) projects * Short Papers (5 pages) - work in progress - small focused contributions - position papers and research perspectives - critical questions and challenges for bx * Talk Proposals (2 pages) - proposed lectures about topics of interest for bx - existing work representing relevant contributions for bx - promising contributions that are not mature enough to be proposed as papers of the other categories If your submission is not a Full Research Paper, please include the intended submission category in the Title field of EasyChair’s submission form. Tool papers, experience reports and short papers will be mapped to the short paper category in CEUR (having between 5-9 standard pages, 1 standard page = 2500 characters), whereas full research papers will be mapped to the regular paper category in CEUR (having at least 10 standard pages). The bibliography is excluded from the page limits. All papers are expected to be self-contained and well-written. Tool papers are not expected to present novel scientific results, but to document artifacts of interest and share bx experience/best practices with the community. Experience papers are expected to report on lessons learnt from applying bx approaches, languages, tools, and theories to practical application case studies. Extended abstracts should primarily provoke interesting discussion at the workshop and will not be held to the same standard of maturity as regular papers; short papers contain focused results, positions or perspectives that can be presented in full in just a few pages, and that correspondingly contain fewer results and that therefore might not be competitive in the full paper category. Talk proposals are expected to present work that is of particular interest to the community and worth a talk slot at the workshop. We strongly encourage authors to ensure that any (variants of) examples are present in the bx example repository at the time of submission, and, for tool papers, to allow for reproducibility with minimal effort, either via a virtual machine (e.g., via Share) or a dedicated website with relevant artifacts and tool access. All submissions will be peer-reviewed by at least three members of the program committee. If a submission is accepted, at least one author is expected to participate in the workshop to present it. Authors of accepted tool paper submissions are also expected to be available to demonstrate their tool at the event. PROCEEDINGS ========================================= The workshop proceedings (in a STAF 2021 joint volume for workshops), including all accepted papers (except talk proposals), shall be submitted after the conference to CEUR-WS.org for online publication. Pre-prints of all papers will be available via the workshop website at the beginning of the conference. Papers must follow the CEUR one column style available at: http://ceur-ws.org/Vol-XXX/CEURART.zip or https://www.overleaf.com/latex/templates/template-for-submissions-to-ceur-w… and must be submitted via EasyChair: https://easychair.org/conferences/?conf=bx2021 Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submissions not complying with the above guidelines may be excluded from the reviewing process without further notice. IMPORTANT DATES ========================================= Abstract submission: April 27, 2021 Paper submission: May 4, 2021 Author notification: May 25, 2021 Early registration: May 27, 2021 Workshop: June 21, 2021 PROGRAM CO-CHAIRS ========================================= The workshop is co-organized by Meng Wang (University of Bristol, UK) and Leen Lambers (Hasso Plattner Institute at the University of Potsdam, Germany). In case of questions, please contact the PC chairs at bx2021(a)easychair.org . Please find further information w.r.t. the Bx 2021 workshop at: http://bx-community.wikidot.com/bx2021:home and STAF 2021 conference at: https://staf2021.hvl.no/ PROGRAM COMMITTEE ========================================= Ravi Chugh, University of Chicago, USA Anthony Cleve, University of Namur, Belgium Alcino Cunha, University of Minho, Portugal Romina Eramo, University of L'Aquila, Italy Michael Johnson, Macquarie University, Australia Hsiang Shang Ko, Academia Sinica, Taiwan Ralf Lämmel, University of Koblenz-Landau, Germany Kazutaka Matsuda, Tohoku University, Japan Fernando Orejas, Universitat Politècnica de Catalunya, Spain Roly Perera, Alan Turing Institute, UK Perdita Stevens, The University of Edinburgh, UK Tarmo Uustalu, Reykjavik University, Iceland Jens Weber, University of Victoria, Canada Bernhard Westfechtel, University of Bayreuth, Germany ========================================= _____________________________________ Leen Lambers Senior Researcher at System Analysis and Modeling Group https://hpi.de/giese/personen/dr-leen-lambers.html _____________________________________ Hasso-Plattner-Institut für Digital Engineering gGmbH Universität Potsdam Prof.-Dr.-Helmert-Str. 2-3 D-14482 Potsdam, Germany _____________________________________ Amtsgericht Potsdam, HRB 12184 Geschäftsführung: Prof. Dr. Christoph Meinel _____________________________________ _______________________________________________ Bx mailing list Bx(a)inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/bx

1 0

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

20 Apr '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/ 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 20, 2021 (extended) - 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

Trick to have existential type work in this case?
by YueCompl 19 Apr '21

19 Apr '21

Dear Cafe, I believe there should exist some trick that I haven't learned, to have this compile: module PoC.Existential where import Data.Dynamic import qualified Data.Vector.Storable as VS import Foreign import Prelude -- * Necessary artifacts data Series a = Series { seriesLen :: IO Int, readSeries :: Int -> IO a } data SomeArray = forall a. (Typeable a, VS.Storable a) => SomeArray { arrayCap :: Int, arrayPtr :: ForeignPtr a } class ManagedArray t where arrayAtTheMoment :: t -> IO SomeArray data SomeManagedArray = forall t. (Typeable t, ManagedArray t) => SomeManagedArray t In following, I can confirm it works with the nested `do` block flattened (as shown later), but I really need it in the more complex real case, so please bear with me. -- * Things not working managedArrayAsSeries :: SomeManagedArray -> IO Dynamic managedArrayAsSeries (SomeManagedArray ma) = do vec <- do SomeArray cap fp <- arrayAtTheMoment ma return $ VS.unsafeFromForeignPtr0 fp cap let len = return $ VS.length vec rs i = return $ vec VS.! i return $ toDyn $ Series len rs The error: src/PoC/Existential.hs:36:5: error: • Couldn't match type ‘a’ with ‘a0’ ‘a’ is a rigid type variable bound by a pattern with constructor: SomeArray :: forall a. (Typeable a, Storable a) => Int -> ForeignPtr a -> SomeArray, in a pattern binding in a 'do' block at src/PoC/Existential.hs:35:5-20 Expected type: IO (VS.Vector a0) Actual type: IO (VS.Vector a) • In a stmt of a 'do' block: return $ VS.unsafeFromForeignPtr0 fp cap In a stmt of a 'do' block: vec <- do SomeArray cap fp <- arrayAtTheMoment ma return $ VS.unsafeFromForeignPtr0 fp cap In the expression: do vec <- do SomeArray cap fp <- arrayAtTheMoment ma return $ VS.unsafeFromForeignPtr0 fp cap let len = return $ VS.length vec rs i = return $ vec VS.! i return $ toDyn $ Series len rs • Relevant bindings include fp :: ForeignPtr a (bound at src/PoC/Existential.hs:35:19) | 36 | return $ VS.unsafeFromForeignPtr0 fp cap | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ While these more trivial things work as expected: -- * Things working managedArrayAsSeries' :: SomeManagedArray -> IO Dynamic managedArrayAsSeries' (SomeManagedArray ma) = do SomeArray cap fp <- arrayAtTheMoment ma let vec = VS.unsafeFromForeignPtr0 fp cap let len = return $ VS.length vec rs i = return $ vec VS.! i return $ toDyn $ Series len rs arrayAsSeries :: SomeArray -> Dynamic arrayAsSeries (SomeArray cap fp) = colAsSeries $ SomeColumn $ VS.unsafeFromForeignPtr0 fp cap arrayAsSeries' :: SomeArray -> Dynamic arrayAsSeries' (SomeArray cap fp) = do let vec = VS.unsafeFromForeignPtr0 fp cap len = return $ VS.length vec rs i = return $ vec VS.! i toDyn $ Series len rs data SomeColumn = forall a. (Typeable a, VS.Storable a) => SomeColumn (VS.Vector a) colAsSeries :: SomeColumn -> Dynamic colAsSeries (SomeColumn colVec) = toDyn $ Series len rs where len = return $ VS.length colVec rs i = return $ colVec VS.! i Please teach me the trick! Thanks with regards, Compl

2 2

How to move files?
by ☂Josh Chia (謝任中) 16 Apr '21

16 Apr '21

I'm trying to write to a temp file in /tmp and then move it to another location that may be in /tmp. If I use System.Directory.renameFile and the final location is in another filesystem, I'll get an error "renameFile:renamePath:rename: unsupported operation (Invalid cross-device link)". If I copy to the new location and then remove the temp file, but the new location is also in /tmp, I am doing an unnecessary copy (instead of mv), which is inefficient. I don't know how to detect whether two filepaths are in the same filesystem. What's the best way to move the file if possible but copy-and-delete if necessary? Josh

9 13

[ANN] wai-handler-hal-0.1.0.0 - Wrap a WAI Application to run on AWS Lambda
by Jack Kelly 15 Apr '21

15 Apr '21

I have just pushed an initial release of wai-handler-hal[1] to Hackage. This library lets you run `wai` `Application`s on AWS Lambda, using the proxy integration features of an API Gateway REST API. This allows you to write your APIs using tools like `servant`, test them locally using `warp`, and then build deployment binaries using `hal`. There's an especially nice payoff when you use `servant`: it's very easy to test the entire API locally using `warp`, but then split endpoints into individual Lambda binaries. This means you can assign minimal IAM policies to each Lambda when you deploy to AWS. The library code, an example API, example deployment code (in AWS CDK[2]), and extensive documentation are all available on GitHub[3]; bug reports and pull requests are welcome. Best, -- Jack [1]: https://hackage.haskell.org/package/wai-handler-hal-0.1.0.0 [2]: https://aws.amazon.com/cdk/ [3]: https://github.com/bellroy/wai-handler-hal

1 0

Re: [Haskell-cafe] Haskell function composition commutivity?
by Dominic Steinitz 15 Apr '21

15 Apr '21

I’d recommend *not* reading Categories for the Working Mathematician unless you are a mathematician (lots of background assumed) and even then it’s a bit of a dull read. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch > From: Viktor Dukhovni <ietf-dane(a)dukhovni.org> > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Haskell function composition commutivity? > Message-ID: <YHYPMnJcYzdEolzl(a)straasha.imrryr.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, Apr 13, 2021 at 02:19:46PM -0500, Galaxy Being wrote: > >> Your answers seem to originate outside of normal Haskell tutorials. Where >> can I start with this higher superset theory? > > There's a reason why the tutorials don't cover this, the categorical > foundations of Haskell types are not beginner material. It is perhaps > best to defer going down this rabbit hole until you're more comfortable > with the Haskell generally. > > You could start with: > > https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-… > https://bartoszmilewski.com/2015/04/07/natural-transformations/ > > For the Yoneda Lemma specifically, I'd recommend: > > http://blog.sigfpe.com/2006/11/yoneda-lemma.html > > Parametricity is covered in "Theorems for free": > > https://www2.cs.sfu.ca/CourseCentral/831/burton/Notes/July14/free.pdf > > but it is by no means elementary, though skimming it for the essential > facts and skipping the gory details is not too difficult. > > You could also read "Categories for the Working Mathematician" by > Saunders Mac Lane.

2 1

serialized data structures (Was: Generalized, named, and exportable default declarations)
by Olaf Klinke 14 Apr '21

14 Apr '21

> We have seen a lot of effort of better integrating Text into Haskell > programming. The only purpose of doing so is to replace String by > something more space and time efficient. What would happen if we invest > equally much time into making String as efficient as Text? At ICFP 2019 I > attended a talk about Gibbon: > > https://github.com/iu-parfunc/gibbon > > The idea of the project is to serialize (Haskell's) tree data structures > in memory as much as possible. Wouldn't this enable us to use String > instead of Text, again, maybe even lists instead of Vectors? No more Text > integration efforts, no more external library with GHC-specific manual > optimizations. Unfortunately, the project is still in an early stage. So > far, it only supports strict data structures. > > What if we would not complicate the language and generalize syntactic > sugar for Text, but instead improve data layout for all Haskell types and > eventually make a custom Text type unnecessary? So essentially Gibbon's aim is to make String work like Text under the hood, without me having to worry about it? +1 for that! Probably I should not comment on this, because I know too little about compilers and serialization. But having to expect something like OverloadedStrings for arbitrary type classes, plus which effect import statements have on this, puts extra cognitive load on the programmer. In contrast, the direction taken by Gibbon removes worries, namely: How much memory penalty do I pay by using this easy-to-understand algebraic data type instead of a more low-level compact representation? I love GHC specifically for its ability to perform many optimizations that Icould not have come up with. Indeed the GHC devs should strive to make the default [*] types work better, as this aligns with the mission of the Haskell Foundation to promote and widen adoption of Haskell. Olaf [*] "default" as dictated by the language report.

2 2

Generalized, named, and exportable default declarations (GHC Proposal)
by Eric Seidel 14 Apr '21

14 Apr '21

Hi Cafe, The GHC Steering Committee is considering a proposal that would expand the typeclass defaulting mechanism to support arbitrary (single-parameter) classes, and enable exporting defaulting rules. It's received very little input from the community so far, which is a shame because it's trying to address a common complaint about Haskell's String situation. Under the proposal Data.Text could export a rule defaulting IsString to Text. Client modules would automatically import defaulting rules just like class instances, which would make ambiguous string literals automatically default to Text. Please take a look at the proposal and leave your feedback, even if it's just "Yes, this would make my life meaningfully better" (reaction emoji are great for this level of feedback). Gauging the amount of pain caused by problems like this, and weighing that against the cost of new features, is one of the harder parts of being on the Committee. PR: https://github.com/ghc-proposals/ghc-proposals/pull/409 Rendered: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/pro…

6 6

Haskell function composition commutivity?
by Galaxy Being 14 Apr '21

14 Apr '21

I'm in chapter 4 of Bird's very interesting *Thinking Functionally with Haskell *and he has a problem at the end of the chapter where he lists these equations map f . take n = take n . map f map f . reverse = reverse . map f map f . sort = sort . map f map f . filter p = map fst . filter snd . map (fork (f,p)) filter (p . g) = map (invertg) . filter p . map g reverse . concat = concat . reverse . map reverse filter p . concat = concat . map (filter p) adding this caveat for the 3rd equation iff x <= y <=> f x <= f y and this for the 4th equation fork (f,g) x = (f x, g x) and for the 5th invertg satisfies invertg . g = id My confusion is over the commutative-ness of most of this but only anecdotally. With the particularly dense map f . filter p = map fst . filter snd . map (fork (f,p)) We have > :t (map myF . filter myP) Integral b => [b] -> [b] > :t (map fst . filter snd . map (myFork (myF,myP))) Integral b => [b] -> [b] Is there anything universal to be drawn from these anecdotal examples of seeming commutativity? My breakdown of the third equation shows the same type definition for both sides. Is this a way to find equality? All in all, Bird doesn't indicate that there are any underlying truths, just "almost" commutativity. LB

3 6