- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Pearl! I just proved theorem about impossibility of monad transformer for parsing with (1) unbiased choice and (2) ambiguity checking before running embedded monadic action (also, I THREAT I will create another parsing lib)
by Askar Safin 22 Jun '21

22 Jun '21

Hi. Thanks for answer! I already wrote arrow parsing lib. I will publish it when I was done. Also, you forgot to add haskell-cafe(a)haskell.org to CC. Понедельник, 21 июня 2021, 21:53 +03:00 от "Olaf Klinke" <olf(a)aatal-apotheke.de>: > Dear Askar, > > your theorem is convincing. While a counterexample is sufficient for a > rigorous proof, I'll try to add some mathematical theory to this. Many > monad transformers are of the form FooT m a = g (m (f a)) where (f,g) > is an adjoint pair of functors. The Kleisli lifting operation (=<<) for > such a composite monad uses the Kleisli lifting of m. For your > application that means that you can not use monadic actions of your > monad transformer without executing the monadic actions of the > transformed monad m. I conjecture that any transformer FooT with the > property that FooT m is a monad provided m is a monad necessarily runs > m-actions. > > A transformer that does not require m to be a monad is the continuation > transformer ContT m r a = (a -> m r) -> m r. However, for this > transformer the lift operation is interdefinable with an operation m (m > r) -> m r so it seems that at least lift will run m-actions. > > As Chris Smith pointed out, this does not rule out that Applicative- > style parsing code may be able to prevent executing the m-actions. > > Olaf > == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar

1 0

Is `MonadBaseControl` dead?
by YueCompl 21 Jun '21

21 Jun '21

Greetings! This is also posted at https://www.reddit.com/r/haskell/comments/o4sggi/is_monadbasecontrol_dead/ <https://www.reddit.com/r/haskell/comments/o4sggi/is_monadbasecontrol_dead/> but I'd like to also seek wider help here. (Background issue I'm facing: https://github.com/snapframework/snap-core/issues/309) I think the functionality of [MonadUnliftIO](https://hackage.haskell.org/package/unliftio-core-0.2.0.1/do… is exactly what I want, but unfortunately [Snap](https://hackage.haskell.org/package/snap-core-1.0.4.2/docs/Snap-Core.… appears not eligible for: > the intuition is that a monad must have no monadic state, but may have monadic context. This essentially limits MonadUnliftIO to ReaderT and IdentityT transformers on top of IO. Then I found `Snap` [has a MonadBaseControl instance](https://hackage.haskell.org/package/snap-core-1.0.4.2/docs/src/Sn…, and thought it should work for me. But sadly to find it [losing states](https://github.com/snapframework/snap-core/issues/309). Also I failed to find a user side example of `MonadBaseControl` on Github ([as there're only instance impl. hits](https://github.com/search?l=Haskell&q=org%3Asnapframework+liftBaseWit…) so I have not way to verify whether that's due to my incorrect usage. Any way quoting u/snoyberg : https://github.com/fpco/unliftio/issues/17#issuecomment-363655106 > Continuation-based monads cannot have instances of MonadUnliftIO, the same as MonadBaseControl and MonadMask. Then I'm not sure `Snap`'s `MonadBaseControl` instance shall really work. Also seems there had been debates I'm not aware of with clue at: https://github.com/fpco/unliftio/tree/master/unliftio#monad-control > > The main contention until now is that unlifting in a transformer like > `StateT` is unsafe. This is not universally true: if only one action > is being unlifted, no ambiguity exists. So, for example, `try :: IO a > -> IO (Either e a)` can safely be unlifted in `StateT`, while `finally > :: IO a -> IO b -> IO a` cannot. > > `monad-control` allows us to unlift both styles. In theory, we could > write a variant of `lifted-base` that never does state discards, and > let `try` be more general than `finally`. In other words, this is an > advantage of `monad-control` over `MonadUnliftIO`. We've avoided > providing any such extra typeclass in this package though, for two > reasons: > > * `MonadUnliftIO` is a simple typeclass, easy to explain. We don't > want to complicated matters (`MonadBaseControl` is a notoriously > difficult to understand typeclass). This simplicity > is captured by the laws for `MonadUnliftIO`, which make the > behavior of the run functions close to that of the already familiar > `lift` and `liftIO`. > * Having this kind of split would be confusing in user code, when > suddenly `finally` is not available to us. We would rather encourage > [good practices](https://www.fpcomplete.com/blog/2017/06/readert-design-pattern) > from the beginning. > > Another distinction is that `monad-control` uses the `MonadBase` > style, allowing unlifting to arbitrary base monads. In this package, > we've elected to go with `MonadIO` style. This limits what we can do > (e.g., no unlifting to `STM`), but we went this way because: > > * In practice, we've found that the vast majority of cases are dealing > with `IO` > * The split in the ecosystem between constraints like `MonadBase IO` > and `MonadIO` leads to significant confusion, and `MonadIO` is by > far the more common constraints (with the typeclass existing in > `base`) > So is `MonadBaseControl` dead or alive? Any user side example for it?

1 0

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

21 Jun '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/ 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: June 30, 2021 (extended) - Acceptance Notification: July 15, 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

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

21 Jun '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: June 30, 2021 (extended) - Acceptance Notification: July 15, 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

Fwd: Haskell colour package repository
by Harendra Kumar 21 Jun '21

21 Jun '21

Does anyone know who maintains the "colour" package or where the repository is hosted? I tried to contact Russell O'Connor but did not get a response. -harendra ---------- Forwarded message --------- From: Harendra Kumar <harendra.kumar(a)gmail.com> Date: Mon, 17 May 2021 at 05:38 Subject: Haskell colour package repository To: <roconnor(a)theorem.ca> Hi, I was building something that depends on https://hackage.haskell.org/package/colour package using GHC-9.3, and it's failing to build. I was wondering if it is possible to add a URL to the package repository in the cabal file of the package so that I can clone/fix/send a PR? Or maybe a URL for reporting issues/bugs? Thanks, Harendra

3 2

Tips for debugging seg. faults?
by David Banas 20 Jun '21

20 Jun '21

Does anyone have any helpful tips for debugging seg. faults in a Haskell program that calls out to a C library, via the FFI?

3 2

Pearl! I just proved theorem about impossibility of monad transformer for parsing with (1) unbiased choice and (2) ambiguity checking before running embedded monadic action (also, I THREAT I will create another parsing lib)
by Askar Safin 18 Jun '21

18 Jun '21

Hi. I hope people here, at haskell-cafe, like various theorem, pearls on parsing, monads, monad transformers and anything like that, right? So, I just proved something interesting for you! Theorem about impossibility of monad transformer for parsing with (1) unbiased choice and (2) ambiguity checking before running embedded monadic action. I already presented it on #haskell in Libera chat, now let me send it here. This is not quite theorem, i. e. I would not say that it keeps with mathematical standards of rigor. --------------------------- I want monad transformer (let's name it ParserT) with following properties (hint: I proved such transformer doesn't exist): - it has unbiased choice (i. e. (<|>) :: ParserT m a -> ParserT m a -> ParserT m a) (this means running parser can give you multiple results) - you can run parser without executing embedded monadic actions. i. e. "run" function should look like this: run :: ParserT m a -> String -> [m a] {- Not m [a] -} I want such function, because I want to do this: run parser, then count number of possible parses, then (if count is equal to one) actually execute embedded monadic action. I. e. I want something like this: parser :: ParserT (Either String) () parser = ..... main :: IO () main = do { input <- ....; case run parser input of { [res] -> do { -- Cool! we got exactly one result! Let's run it case res of { Left e -> putStr $ "Parsing succeed, but we have semantic error: " ++ e; Right () -> putStr "Everything OK"; }; }; _ -> putStr "Cannot parse. 0 parse trees or >1 parse trees"; }; } Now let me state theorem. Theorem. Such transformer doesn't exist. Moreover, even if I replace arbitrary monad "m" with particular monad "Maybe" (or "Either String") the task is still unsolvable. But the task seems achievable using arrows ------------------------------------- Proof. Let's imagine such "ParsecT Maybe" exists. Let's imagine we have such function: char :: Char -> ParserT Maybe Char {- matches supplied char -} Also, keep in mind we have "lift": lift :: Maybe a -> ParserT Maybe a Now let's write this: parseA = char 'a' parseAorA = char 'a' <|> char 'a' contr = do { a <- lift $ Nothing; if a > 5 then parseA else parseAorA; return (); } Now, please, say, what is (run contr "a")? How many elements will (run contr "a") have? If "a > 5", then (run contr "a") will contain one element. If "a <= 5", then (run contr "a") will contain two elements. But we cannot know whether "a > 5", because we cannot extract "a" from "Nothing". So, we got contradiction. QED ----------------- In other words, function "run" with type "ParserT m a -> String -> [m a]" means that we should somehow be able to know count of parses before executing monadic action. But this is impossible, because our parser can contain code like this: (do { a <- lift $ ...; if a then ... else ...; }). I. e. count of parses can depend on value, embedded in inner monad, so we cannot know count of parses before we run embedded inner monadic action. This theorem is not simply out of curiosity. I actually need parsing lib with this properties. 1. I need unbiased choice, because it is compatible with CFGs, and I love CFGs (as opposed to PEG) 2. I need embedding monads, because this allows me to check semantic errors (such as "type mismatch") in time of parsing. I. e. I can simply embed (Either String) monad into parsing monad, and use this (Either String) monad for checking semantic errors 3. I need to know number of parse trees before executing monadic actions (i. e. i need ([m a]) as opposed to (m [a])), because I want to check that number of parses is equal to 1 (if not, then print error), and then extract inner monad (which will contain information about semantic errors). In other words, I want check the input for ambiguity (and print error if it is ambiguous), and if it is not ambiguous, then print possible semantic errors (if any). The possibility of ambiguity detection is whole point of using CFGs as opposed to PEGs (which are always unambiguous, but this unambiguity is simply trick). 4. Every terminal and nonterminal should carry location info (i. e. begin and end of this string). And this location info should be passed implicitly. And it should not be embedded deeply in ASTs I will use. (This means that "happy" is not for me. As well as I understand it cannot implicitly pass location info. In https://github.com/ghc/ghc/blob/master/compiler/GHC/Parser.y I see explicit location management all the time.) 5. Left recursion is not needed So, does such lib exist? Well, I already know such lib should be arrow based (as opposed to monad). So, is there such arrow parsing lib? Embedding arbitrary inner monad is not needed, just embedding (Either String) will go. If there is no such lib, I plan to create my own. This is threat! :) Also, I wrote letter long ago asking for parsing lib with different properties. I included desire for reversibility, among others. Well, this was other task. For my current task I don't need reversibility. == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar

3 5

ICFP 2021 Student Research Competition: Call for Submissions
by Sam Tobin-Hochstadt 17 Jun '21

17 Jun '21

ICFP 2021 Student Research Competition Call for Submissions ICFP invites students to participate in the Student Research Competition, which will be held virtually alongside the main conference, in order to present their research and receive feedback from prominent members of the programming language research community. As usual, the SRC consists of three rounds: * Extended abstract * Poster session at ICFP 2021 * ICFP presentation To make the virtual competition fruitful, we will make sure that every student will have an "invited audience" during the poster session. We are also planning to organize a social event for the students. Please visit the SRC website for updates. ### Important Dates Submissions due: 2 July 2021 (Friday) https://icfp21src.hotcrp.com Notification: 16 July 2021 (Friday) Conference: 22 August (Sunday) - 27 August (Friday) ### Submission Details Each submission (referred to as "abstract" below) should include the student author’s name and e-mail address; institutional affiliation; research advisor’s name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and*or part of a larger group project, the abstract should make clear what the student’s role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp21.sigplan.org/track/icfp-2021-Student-Research-Competition Program Committee: Chair: Anders Miltner (UT Austin) Andreea Costea (NUS Singapore) Andrew Hirsch (MPI-SWS) Liam O'Connor (University of Edinburgh) Lionel Parreaux (HKUST) Daming Zou (ETH Zurich)

1 0

An emotional retrospective on my Haskell journey so far
by Chris Smith 17 Jun '21

17 Jun '21

Hi everyone, I started out writing a blog post about why I chose to become a contributor to the Haskell Foundation. It ended up being a bit of a bigger picture recap of my whole Haskell journey. I would like to share it with you, since many of the people here have been really influential to me over the past 15 years. Thank you all so much. Link: https://cdsmithus.medium.com/why-i-support-the-haskell-foundation-1ac3cda1f… Yes, it's Medium, but it isn't part of their soft paywall, so please don't be afraid to click on it. Cheers, Chris Smith

1 0

Fwd: Haskell grammar ambiguity
by Jon Purdy 17 Jun '21

17 Jun '21

Email fail, pardon the noise; original message below. ---------- Forwarded message --------- From: Jon Purdy <evincarofautumn(a)gmail.com> Date: Wed, Jun 16, 2021 at 1:35 PM Subject: Re: [Haskell-cafe] Haskell grammar ambiguity To: Sven Panne <svenpanne(a)gmail.com> On Wed, Jun 16, 2021 at 12:49 AM Sven Panne <svenpanne(a)gmail.com> wrote: > I consider ambiguous grammars a serious usability bug. > I agree. I always make a point of telling ‘%expect 0’ to Happy. (“More often than not the grammar you write will have conflicts”? Excuse you!) > The BlockArguments proposal introduced lots of additional ambiguities, and > that's the reason why I'm still opposed to it. > I consider BlockArguments a fix for a bug in the Haskell grammar, namely, a redundant production, requiring an unnecessary operator, which causes confusion for some people coming from other languages. In being fixed, however, it exposed other serious grammar issues. So I’d be strongly in favour of fixing those unclear/ambiguous parses by further (incremental) simplification of the grammar. It would be very nice if the extent of lambda/if/&c. were unambiguous, so I think this idea is a step in the right direction. I would also be very pleased if the layout rule were reformulated as a simpler desugaring step, from a token stream annotated with source locations to such a stream with explicit braces and semicolons inserted, rather than being defined in terms of parse errors and papering over edge cases. My ideal would be a simple formal grammar (LALR, PEG, or even operator-precedence) which is machine-validated as unambiguous, with an implementation written by hand to produce nice contextual error messages, which is typed to prove that it accepts the same language as the formal grammar.

1 0