- Haskell-Cafe - Haskell.org

Z.Haskell project announced
by Dong Han 07 Apr '21

07 Apr '21

Dear Haskellers: After having a discussion with HF guys, I decide to announce [Z.Haskell]( http://z.haskell.world/) project, It's available on Hackage and very much usable now, the document is also pretty adequate. To recap the document from Z.Haskell, Z.Haskell provides: + Array, vector(array slice), sorting, searching + Text based UTF-8, basic Unicode manipulating, regex + FFI utilities + Fast parsing and building monad + JSON encoding and decoding + IO resource management, resource pool + File system operations + Network: DNS, TCP, UDP and IPC + Buffered input and output + Process management + Environment settings + High performance logger + High performance low-resolution timer The project's goal is not to compete with the base, but to provide an alternative engineering toolkit, which is more suitable for writing practical network/storage services. Similar to [netty](https://netty.io/) for java or [nodejs](https://nodejs.org/) for javascript. Welcome to join Z.Haskell if you have a similar use case. Currently, we're heading with the following roadmap: + Crypto library based on [botan](https://github.com/ZHaskell/z-botan). + TLS network stack. + HTTP framework. + Distributed system algorithms. Happy hacking! Z.Haskell Contributors

2 2

Get proof of injectivity for an injective type family
by Andreas Källberg 07 Apr '21

07 Apr '21

Is there any way to get hold of a proof of injectivity for an injective type family? In other words, given this type family type family F a = b | b -> a can I get the term fInj :: F a ~ F b => (a ~ b => r) -> r in any way (without using unsafeCoerce)?

3 2

[ANN] aws-arn-0.1.0.0 - Library and optics for munging Amazon Resource Names (ARNs)
by Jack Kelly 07 Apr '21

07 Apr '21

I have just pushed an initial release of aws-arn[1] to Hackage. This library provides a type representing Amazon Resource Names (ARNs)[2], and parsing/unparsing functions for them. The provided optics make it very convenient to rewrite parts of ARNs. An example, from the documentation: API Gateway Lambda Authorizers are given the ARN of the requested endpoint and method, and are expected to respond with an IAM Policy Document. It is sometimes useful to manipulate the given ARN when describing which resources to authorize: -- Returns "arn:aws:execute-api:us-east-1:123456789012:my-spiffy-api/stage/*" let authorizerSampleARN = "arn:aws:execute-api:us-east-1:123456789012:my-spiffy-api/stage/GET/some/deep/path" in over (_ARN . arnResource . slashes) (\parts -> take 2 parts ++ ["*"]) authorizerSampleARN The code is available on GitHub[3]; bug reports and pull requests are welcome. There is some additional support for parsing specific resource types -- PRs to support more resource types are especially welcome. Best, -- Jack [1]: https://hackage.haskell.org/package/aws-arn-0.1.0.0 [2]: https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html [3]: https://github.com/bellroy/aws-arn

1 0

Looking for a toy imperative language implementation in Haskell for research
by Igor Moreno Santos 07 Apr '21

07 Apr '21

Hi, I'm looking for a toy imperative language implementation in Haskell for research purposes. I imagine something like the language of arithmetic expressions from TAPL ch. 3 augmented with - while-loop (so the CFG has loops) - blocks (sequence of statements to put inside loops and conditionals) - assignment (otherwise we can't show any effects from sequences) I think there's probably nothing exactly like that so we might end up doing it ourselves but maybe there's already something out there. Thank you in advance. Regards, Igor Moreno

7 6

A functor for two Peano systems
by Galaxy Being 06 Apr '21

06 Apr '21

I'm just not understanding the concept of a functor in this context: I have this plus :: Int -> Int -> Int plus n m = if (n == 0) then m else sCessor (plus (pCessor n) m) where sCessor x = x + 1 pCessor x = if (x == 0) then error "too small" else (x - 1) and this data MyNum = MNZero | OneMoreThan MyNum deriving (Show,Eq,Ord) plus2 :: MyNum -> MyNum -> MyNum plus2 n m = if (n == MNZero) then m else sCessor (plus2 (pCessor n) m) where sCessor x = (OneMoreThan x) pCessor x = if (x == MNZero) then (error "too small") else (oneLess x) oneLess MNZero = MNZero oneLess (OneMoreThan myn) = myn It seems there should be just one plus, function that would handle both an Int-based Peano and the MyNum-based Peano, not two. But in this definition fmap :: (a -> b) -> f a -> f b The (a -> b) should be "lifted" over the f a -> f b But I can't conceive of how this should all fit together, i.e., to create just one generic plus that would handle both the plus :: Int -> Int -> Int and the plus2 :: MyNum -> MyNum -> MyNum. Trying to get started, I would assume I need some sort of instance Functor MyNum describing, yeah, what? Or am I barking up the completely wrong tree here, i.e., this isn't a functor issue? LB

3 3

How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency
by YueCompl 06 Apr '21

06 Apr '21

Hello Cafe and respected GHC Devs, I would like to ensure some immutable vectors (can be quite large) are always shared instead of copied, and I think that should be straight forward w.r.t. referential transparency we enjoy. In an attempt to determine whether two immutable vectors can be treated as the same one to enable specific optimizations for that case, I tried to use ST to determine their respective backing foreign ptrs for comparison. But appears it can be copied when wrapped in a newtype, I wonder why it is the case, and how to avoid the copy? Here's my minimum reproducible snippet: ```hs λ> :set -XBangPatterns λ> λ> :set -package vector package flags have changed, resetting and loading new packages... λ> λ> import Prelude λ> λ> import Control.Monad.ST λ> import qualified Data.Vector.Storable as VS λ> λ> :{ λ| λ| newtype SomeVector = SomeVector (VS.Vector Int) λ| λ| isSameVector :: SomeVector -> SomeVector -> Bool λ| isSameVector (SomeVector !x) (SomeVector !y) = runST $ do λ| mx(a)(VS.MVector !x'offset !x'fp) <- VS.unsafeThaw x λ| my(a)(VS.MVector !y'offset !y'fp) <- VS.unsafeThaw y λ| _ <- VS.unsafeFreeze mx λ| _ <- VS.unsafeFreeze my λ| return $ x'offset == y'offset && x'fp == y'fp λ| λ| :} λ> λ> let !v = VS.fromList [3,2,5] in isSameVector (SomeVector v) (SomeVector v) False λ> λ> let !v = SomeVector (VS.fromList [3,2,5]) in isSameVector v v True λ> ``` Thanks with best regards, Compl

3 10

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

06 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

Re: [Haskell-cafe] A functor for two Peano systems
by Anthony Clayden 06 Apr '21

06 Apr '21

> This whole exercise is my attempt to translate *The Littler MLer* and its last chapter where they go into functors. That approach isn't working for you, and it's trying the patience of the cafe. (These are sub-beginner level q's, please use the Beginners' forum. And I'd forgotten that's what you're doing. Your first post in this thread should have said you're talking about ML functors. https://stackoverflow.com/questions/2030863/in-functional-programming-what-…. says "most beginning programmers have difficulty with [functors]".) I suggest you first go through a Haskell tutorial, and get your knowledge secure of idiomatic Haskell. Even so, I just don't believe you're coming from idiomatic ML. Unless 'The Little MLer' is giving it as obfuscated code, and the objective is to de-obfuscate it. I'd code your `plus2` with pattern-matching: > plus2 :: MyNum -> MyNum -> MyNum > plus2 MNZero m = m > plus2 (OneMoreThan n') m = OneMoreThan $ plus2 n' m Your test for `(x == MNZero)` inside helper function `pCessor` is useless: flow-of-control doesn't take the outer `else` branch unless `x` (i.e. `n`) is _not_ equal `MNZero`. Similar redundant code in the case for `Int`. But that has bigger problems, as Olaf points out: `Int`s can be negative. So if `plus` is called with a negative `n`, it'll call `pCessor` repeatedly until stack overflow (or numeric underflow). AntC

4 3

Designing a "living will" for my packages on Hackage
by Tom Ellis 06 Apr '21

06 Apr '21

# Introduction Over the past few weeks I've seen several instances of difficulty caused by unavailable or unknown package maintainers. I want to minimise the risk that difficulties arise for users of my packages should I ever become unavailable or uncontactable. I'd like to brainstorm policies for achieving this. My immediate goal is to find a suitable policy to apply to my own packages but I also have an indirect goal that the policy be suitable and appealing for others to apply to their packages on a voluntary basis. # What already exists? ## My packages already have backup maintainers I am already fortunate enough to have backup maintainers who have agreed to make bugfixes and dependency version bumps should I become unreachable: https://github.com/tomjaguarpaw/haskell-opaleye#backup-maintainers Two caveats: * Bugfixes and dependency version bumps are really the absolute minimum needed to ensure continuity of service. Much more is needed for the general health and reliability of a package. * It has been a long time since I contacted these maintainers and asked for their help in this matter. Perhaps if they were called upon now they would no longer have the time to fulfil this role. Perhaps I should ask the backup maintainers every 12 months whether they are willing to continue in the role. If not then that would give me the impetus to find other backup maintainers. ## Do established policies like this already exist? Perhaps effective backup maintainer policies already exist in the Haskell community or in other language communities? Does anyone know? I would be grateful to find out. # A simple proposal I'd like to propose something simple that avoids anything too legalistic or requires multilateral cooperation. For example, if I had three backup X, Y and Z, I could do the following: * Add these paragraphs to the README In the event that the maintainer has been unavailable and uncontactable for _three months_ then X is entitled to claim ownership of the package. In the event that the maintainer has been unavailable and uncontactable for _four months_ then Y is entitled to claim ownership of the package. In the event that the maintainer has been unavailable and uncontactable for _five months_ then Z is entitled to claim ownership of the package. "The maintainer has been unavailable and uncontactable" means that the maintainer has not made any commits to the repository nor has been contactable by email [or precise other conditions to be determined]. [Once a backup maintainer has claimed ownership they are entitled to do essentially whatever they like with the package, though I would choose them responsibly so that they continue maintaining the package in a sensible way!] * Give the backup maintainers write access to the package git repository and to the package Hackage entry, effective immediately I would choose the backup maintainers carefully so that I trust them not to take drastic actions with the package unless and until the conditions stated in the README are met. * Clarify with the backup maintainers every year that they are still willing to step in in case I become unavailable. If not I'll find replacements. ## Questions about the simple proposal * "Isn't this just the standard practice of having multiple maintainers?" Basically yes, but with the added benefit that the inheritance and ownership procedure is defined clearly. Hopefully that reassures users and developers about the future of the package. * "After 4 months have elapsed what stops X and Y trying to claim ownership at the same time?" Well, not really anything. The first to claim it gets it. But after three months have elapsed I suggest that X take ownership and change the policy, replacing her name with mine. I hope she also deems Y and Z to be good backup maintainers and keeps them in place! * "How many backup maintainers should there be?" I suppose that depends on the package. For my packages I'd probably like two or three. Having only one backup maintainer doesn't set my mind at ease. Four seems a bit too much! * "How long should elapse before claiming ownership is permitted?" Again that depends on the package. For my packages three months of my absence seems reasonable, plus one month per additional backup maintainer to give each a reasonable time to claim the package. ## What do you think? What do people think? Will this simple policy achieve my goal of achieving a smooth transfer of maintainership if I become available? Are there any caveats that make the policy unworkable or undesirable? Is there something about it that would make others averse to apply it to their packages? Is there some easy way to make it better? Cheers, Tom

3 2

Re: [Haskell-cafe] A functor for two Peano systems
by Olaf Klinke 05 Apr '21

05 Apr '21

You should try to 1. destill which basic operations are necessary on the types Int, MyNum to make your algorithms work, 2. write a type class for these operations, 3. write type class instances for Int and MyNum, 4. write a generic algorithm that works for all members your class, which ideally looks almost identical to the specific code you already have. I dare say this is a common way of reducing boilerplate code in Haskell. BTW, you should consider Numeric.Natural instead of Int for Peano addition. Cheers Olaf

1 0

Re: [Haskell-cafe] A functor for two Peano systems
by Anthony Clayden 05 Apr '21

05 Apr '21

> Or am I barking up the completely wrong tree here, i.e., this isn't a functor issue? Yes you are barking up the wrong tree/no this isn't a Functor issue. > create just one generic plus that would handle both the plus :: Int -> Int -> Int and the plus2 :: MyNum -> MyNum -> MyNum. A Functor would need to be of the form of a parameterised type. That is, the `f` in `f a`. Neither `Int` nor `MyNum` are parameterised. You want a plus-like method that's polymorphic/generic across different Peano-like numeric representations. IOW you want an overloading. That's what typeclasses are for: > class PolyPlus a where polyPlus :: a -> a -> a > > instance PolyPlus Int where polyPlus = plus > > instance PolyPlus MyNum where polyPlus = plus2 (In those instances you could just put the definitions for those functions/no need to define them separately. BTW both those definitions are truly horrible non-idiomatic Haskell. Why are you trying to write C code in Haskell?) AntC

3 2

Re: [Haskell-cafe] Existential type variables in constraints
by Anthony Clayden 05 Apr '21

05 Apr '21

> because UndecidableInstances is definitely required for this and I know it's a problematic one. Hi Juan, I'll knock that on the head at once. `UndecidableInstances` is not "problematic" (or at least it's far less problematic than others you list). Although we're lacking a proof that it can't lead to incoherence/type unsafety, nobody's demonstrated unsafety due to `UndecidableInstances` alone -- that is, providing the program compiles (i.e. instance resolution terminates). OTOH `FlexibleInstances` can give `OverlappingInstances` -- maybe overlapping with those in some other module, thus giving the dreaded Orphan instances problems. I'd be much more concerned about them. > instance (Ord a, forall b c. (Ord b, Ord c)) => Class1 a where > fun1 = (<) Why does that even mention `b` or `c`? There's no FunDep from `a`, to get a FunDep there'd be a constraint `D a b c` or something. They seem totally redundant. > completely overlooked by the compiler Yes. Quite. What do you expect the compiler to do? Even if the class decl gave a signature for `fun1` mentioning `b`, `c`, those would be _distinct_ tyvars, because they're not scoped in the class head. > is there any way I can make this work? Sorry, I don't know what you want to "work". Please at least show a class decl with a FunDep. From your second message: > it is possible in principle that (Ord a, Ord b) produces a functional dependency between a and b No it isn't possible, even in principle: `(..., ...)` is a tuple constructor, not a class; therefore no FunDep could apply. AntC

3 4

Existential type variables in constraints
by CASANOVA Juan 03 Apr '21

03 Apr '21

Hello again, Here with more type class issues. As usual, assume all extensions required. But here I am going to be explicit, because UndecidableInstances is definitely required for this and I know it's a problematic one. These may be excessive, but with these extensions this should work: {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeSynonymInstances #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE LiberalTypeSynonyms #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE ConstraintKinds #-} My "problem" is I want (almost need) existentially quantified types in constraints. The reason is that I have lots, lots and lots of constraints over up to 10 type variables (multi-parameter type classes in most cases, with complex functional dependencies), which are trickled down over multiple layers of functions over multiple modules. So what I do is I define some global type synonyms that combine families of these constraints, usually the ones that are used in a specific module. Something like: type ModuleAConstraints a b c d = (Ord a, Ord b , Ord c, Class1 a b, Class2 a [c], Class3 [(c,a)] (a -> d [b])) (the specific constraints are made up, mine are much more and more complicated, but you get the idea of the liberality of the constraints) Now, what happens is that in one of the highest-level modules, some of the type variables begin to disappear because they are only used internally in the lower-level modules. The functional dependencies ensure that, once I instantiate the remaining type variables, those type variables will have only one possible result, for which I will have an implemented instance. But my type synonyms include them, and I need them to use the lower-level functions. No problem, you can have existentially quantified variables in constraints. For example, this works: class Class1 a where fun1 :: a -> a -> Bool instance (Ord a, forall b. Ord b) => Class1 a where fun1 = (<) You can also do this with type synonyms and group constraints into pairs. For example, the two following equivalent alternatives work (same definition of Class1): 1: instance (Ord a, forall b c. (Ord b, Ord c)) => Class1 a where fun1 = (<) 2: type CType b c = (Ord b, Ord c) instance (Ord a, forall b c. CType b c) => Class1 a where fun1 = (<) But, it seems, any constraints under the existentially quantifier that only utilize non-quantified variables seems to be completely overlooked by the compiler. As such, the following two equivalent alternatives both fail to type check, telling me that it cannot deduce (Ord a): 3: instance (forall b. (Ord a, Ord b)) => Class1 a where fun1 = (<) 4: type CType a b = (Ord a, Ord b) instance (forall b. CType a b) => Class1 a where fun1 = (<) Is there a good reason for this? It could be a good reason in the sense of: The deduction would be incorrect; or a good reason in the sense of: The compiler would need to do undecidable things to be able to deduce that in general. But right now I cannot see a reason. I honestly cannot see how it could be hard for the compiler to realize that instance (Ord a, forall b. Ord b) => Class1 a where fun1 = (<) and instance (forall b. (Ord a, Ord b)) => Class1 a where fun1 = (<) are equivalent. But it doesn't. Also, is there any way I can make this work? Right now, the only option I can see is to manually re-enumerate all of the constraints that do not include the quantified variable and use that. I guess I can do that and it would only take around an hour... but what a boring and tedious hour, and to be fair I was going to stop for today anyway so I thought I'd throw the question on Haskell Cafe. I hope that's okay 🙂. Thanks in advance as usual. Juan Casanova. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

2 2

Eq source code?
by Galaxy Being 02 Apr '21

02 Apr '21

While learning about type classes, I tried to find the actual source code for Eq. In my beginner books this much is typically given class Eq a where (==), (/=) :: a -> a -> Bool -- Minimal completion definition: x /= y = not (x == y) x == y = not (x /= y) I then found this <https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Eq.html> at hackage.haskell.org, but the "source" links are dead. On this page is a section of what I can't tell is either source code or just commentary on all the different mathematical ideas about equality, i.e., Reflexivity x == x = True Symmetry x == y = y == x Transitivity if x == y && y == z = True, then x == z = True Substitutivity if x == y = True and f is a "public" function whose return type is an instance of Eq, then f x == f y = True Negation x /= y = not (x == y) I would like to know if this is indeed in the source code or if it's just a sort of commentary. It looks important. Where can I find the actual source for all these basic type classes? LB

3 3

Hackage dependencies
by Aaron Gray 02 Apr '21

02 Apr '21

Hi, Is there a tool or web access to give a list off all Hackage packages dependent upon a Hackage package, please ? Regards, Aaron -- Aaron Gray Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and Computer Scientist.

3 3

Bx 2021 - CALL FOR PAPERS
by Meng Wang 31 Mar '21

31 Mar '21

To Haskellers, Bidirectional Transformations (Bx) are also known as lenses! Please consider submitting your Haskell-related papers which are very welcome. Best regards, Meng Meng Wang, PhD (Oxon) University of Bristol Senior Lecturer of Programming Languages Head of PL research group International Director of SCEEM (CS, EEE, EMath) School ********************************************************************************** 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. 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 (5-9 standard pages, 1 standard page = 2500 characters), whereas full research papers will be mapped to the regular paper category in CEUR (min. 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 =========================================

1 0

Injective type classes?
by Tom Smeding 30 Mar '21

30 Mar '21

Hi Cafe, With this class definition with this instance: class C a where instance C b => C (a, b) GHC can of course infer, given 'C b', that 'C (a, b)'. This is nothing more than the meaning of the instance declaration above. However, GHC cannot infer the inverse: {-# LANGUAGE FlexibleContexts #-} foo :: C a => a -> Int foo = undefined bar1 :: C (a, b) => a -> b -> Int bar1 _ = foo This gives an error on the right-hand side of 'bar1': "Could not deduce (C b) arising from a use of ‘foo’; from the context: C (a, b)". The same happens in similar cases: {-# LANGUAGE GADTs #-} bar2 :: (C p, p ~ (a, b)) => a -> b -> Int bar2 _ = foo data Thing a where Tup :: a -> b -> Thing (a, b) bar3 :: C a => Thing a -> Int bar3 (Tup x y) = foo y Both these usages of 'foo' yield the same error. My use-case is 'bar3', where I would like GHC to determine that the call to 'foo' is valid. (I don't actually care directly about bar1 and bar2.) Is there a way to make 'bar3' compile? Note that: - In my actual use case, 'C' is of course not empty. - In my actual use case, my type class instances _are_ in fact injective, even though I do enable FlexibleInstances to be able to write e.g. 'instance C (T a Int)'. - Above, the dictionary for 'C (a, b)' includes a dictionary for 'C b', doesn't it? So if inference can resolve 'C b', then the compilation to Core can find the right dictionary, I think? (Not sure about this part.) Thanks a lot for your help. Cheers, Tom

4 5

Maybe won't let me count
by Galaxy Being 30 Mar '21

30 Mar '21

I've got this import Data.Maybe data MyList a = Empty | Cons a (MyList a) deriving (Eq,Ord,Show) data BaconOrIndex = Bacon | Indx Int deriving (Eq,Ord,Show) whereIsBM Empty = Nothing whereIsBM (Cons idx lx) = if (idx == Bacon) then Just 1 else (whereIsBM lx) which I would like to tell me where the Bacon is (index), not just if there's Bacon, which is what it does now. That is, I need this to happen > whereIsBM (Cons (Indx 5) (Cons Bacon (Cons (Indx 2) (Cons (Indx 8) Empty)))) Just 2 So I need to traverse a BaconOrIndex list and count how deep I went to find the Bacon variable. I get the above code to evaluate error-free, but obviously I'm only returning a Just 1 when it sees Bacon. What I need is to have the last part be . . . else (1 + whereIsBM lx) work; but it keeps giving the error Non type-variable argument in the constraint: Num (Maybe a) (Use FlexibleContexts to permit this) • When checking the inferred type whereIsBM :: forall a. (Num a, Num (Maybe a)) => MyList BaconOrIndex -> Maybe a I haven't a clue what this means. Eventually, I'll wrap this in something that handles the Nothing and does fromJust on the alternative. This whole effort is because if I didn't use the Maybe strategy, and said whereIsBM Empty = 0 ... it would never give back 0 if it didn't find Bacon, rather, it would simply return the whole countdown to Empty. What can I do to make Maybe work here? LB

7 12

Why Haskell?
by Clinton Mead 29 Mar '21

29 Mar '21

I’m looking for recommendations of videos/articles to show to a software development manager about why one should use Haskell, focused more from a benefits to business perspective. Naturally this may involve some code, this manager isn’t completely clueless when it comes to programming languages, but basically something that explains why I’m raving about this “Haskell” thing all the time and why it’s a good idea. Thanks, Clinton

12 16

Arrays in base... (was: ... indexing lists)
by Viktor Dukhovni 29 Mar '21

29 Mar '21

On Mon, Mar 29, 2021 at 10:58:49AM +0200, Henning Thielemann wrote: > On Mon, 29 Mar 2021, Viktor Dukhovni wrote: > > > Thus I applaud Michael Snoyman's quest to address the absense of a basic > > array type in the `base` library. Perhaps more users would stop abusing > > lists (memoisable iterators) as an indexed store. > > Data.Array actually _was_ part of base-3. > > However, I think we should split 'base' in more smaller parts rather than > making it bigger. FWIW, I don't think that splitting base into multiple libraries would achieves much, it would likely raise the cost of coordinating versioning. I do however agree that perhaps separating base from GHC could be a good idea, if GHC could ship a smaller foundational library with primops, ... and `base` evolved somewhat independently. However that too has potential drawbacks, because packages would be more likely to have non-overlapping version bounds on a separately evolving base... Probably manageable, but something to keep in mind. -- Viktor.

3 2

Munich Virtual Haskell Meeting, 2021-03-31 @ 19:30
by Leah Neukirchen 29 Mar '21

29 Mar '21

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 31 on Google Meet at 19:30 CEST. **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: https://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

Why does my module take so long to compile?
by Troels Henriksen 28 Mar '21

28 Mar '21

I have a program with about 220 modules. One of these modules takes _much_ longer to compile than the others (several minutes longer). I don't understand why. It compiled much faster with GHC 8.8.3, but got orders of magnitude slower when I changed to GHC 8.10.2. I don't understand why, since I don't think there is nothing special about the module - e.g. no type-level programming. Is there any good way to "profile" the stack or cabal compilation process to at least get an intuition for what takes so long? Note that the module is in the middle of the dependency tree of my program, so it is not viable to separate it out and compile it manually with GHC. It's slow even when I pass '--fast' to stack which should disable the optimiser, so I guess the type checker may be spending a lot of time on handling the admittedly large amount of typeclass constraints I have on some of my definitions. I'm mostly looking for techniques and tools I can also use next time this problem occurs, not the specific problem here, but if anyone's curious, the module in question is this one: https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKern… -- \ Troels /\ Henriksen

6 13

Some questions about Fudgets library
by Antonio 28 Mar '21

28 Mar '21

I wonder why there is no Fudgets package in Hackage. I found this, but the fudgets link is broken: http://hackage.haskell.org/user/ThomasHallgren Nevertheless, there is a cabalized package in the Fudgets homepage, so it's strange it's not in Hackage. Also, is there an arrowized version of Fudgets? If not, why? Is there some fundamental reason that makes it impossible to port it to the arrows framework or simply nobody cared to port it? (Also, the license seems to not allow modifications.) I'm trying to write a bittorrent client in Haskell. I decided to use arrows for it and took a look at Fudgets and Yampa. I haven't decided yet which one to use. Fudgets seems more suitable and I like it more, but the fact that it doesn't use the arrow notation and classes is a bit annoying. I read that Fruit is more or less a mix of Fudgets and Yampa that uses arrows. Sadly, it's unmaintained, the web doesn't exist and it's not in Hackage. Is there any other Fudgets-like option? Greetings.

4 5

Install on Ubuntu
by Galaxy Being 28 Mar '21

28 Mar '21

I've found a Haskell setup guide here, but after the stack setup it wants to install cabal curl -sSL https://get.haskellstack.org | sh then stack install cabal-install cabal update Why do I want to install cabal after stack? Any advice welcome on the "definitive setup." Just started a new machine with Ubuntu 20.10 on it. LB

3 4

Does Haskell have this SML syntax?
by Galaxy Being 27 Mar '21

27 Mar '21

I saw this in *The Little MLer*, a book on SML datatype 'a list = Empty | Cons of 'a * 'a list fun subst_c (pred) = fn (n,Empty) => Empty | (n,Cons(e,t)) => if pred (e) then Cons (n,subst_c (pred) (n,t)) else Cons (e,subst_c (pred) (n,t)) The data type is just a homemade list, and the function subst_c takes a predicate ('a -> Bool) and determines whether an incoming list's elements pass or fail. What is interesting is the fn ... => ... part which takes in more parameters, namely an 'a and an 'a list. Technically this fn... is an anonymous, nameless function, and it seems bizarre to me that it's nested inside the named function but still taking in parameters as if it were at the top level. Here's a previous version showing all three parameters at the top level fun subst_c (pred) (n,Empty) = Empty ... The purpose of the first function was to demonstrate currying. IOW, what the second unnamed function is doing behind the scenes can be broken down to two-stages (currying) of the first with named, then unnamed functions. So my question is, is there anything like this in Haskell where a function inside a function -- named or anonymous -- can take incoming parameters as if it were top level? LB

4 6

Query regarding GSOC
by Shubham Mittal 25 Mar '21

25 Mar '21

Hello I am Shubham from India currently pursuing BTech IT 2nd year. I would like to contribute to Haskell-Cafe as a part of GSOC. Can you please guide me how I can i do so? Thanks and Regards, Shubham Mittal

1 0

IFL2021 First call for papers
by Pieter Koopman 24 Mar '21

24 Mar '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> ================================================================================ Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2021 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Industrial track and topics of interest This year's edition of IFL explicitly solicits original work concerning *applications* of functional programming in industry and academia. These contributions will be reviewed by experts with an industrial background. Topics of interest to IFL include, but are not limited to: * language concepts * type systems, type checking, type inferencing * compilation techniques * staged compilation * run-time function specialisation * run-time code generation * partial evaluation * (abstract) interpretation * meta-programming * generic programming * automatic program generation * array processing * concurrent/parallel programming * concurrent/parallel program execution * embedded systems * web applications * (embedded) domain-specific languages * security * novel memory management techniques * run-time profiling performance measurements * debugging and tracing * testing and proofing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * applications of functional programming in the industry, including ** functional programming techniques for large applications ** successes of the application functional programming ** challenges for functional programming encountered ** any topic related to the application of functional programming that is interesting for the IFL community Post-symposium peer-review Following IFL tradition, IFL 2021 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. Moreover, the proceedings will also be made publicly available as open access. Important dates Submission deadline of draft papers: 17 August 2021 Notification of acceptance for presentation: 19 August 2021 Registration deadline: 30 August 2021 IFL Symposium: 1-3 September 2021 Submission of papers for proceedings: 6 December 2021 Notification of acceptance: 3 February 2022 Camera-ready version: 15 March 2022 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Organisation IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands PC (under construction): Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary Virtual symposium Because of the Covid-19 pandemic, this year IFL 2021 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here. [image: beacon]

1 0

ANN closed-intervals-0.1
by Olaf Klinke 24 Mar '21

24 Mar '21

Dear Cafe, I am pleased to announce the first release of closed-intervals [1], a package for querying and manipulating collections of closed intervals in totally ordered types. Other packages exist which either deal with a single interval type [2,4] or provide an interval type class [3]. Having both closed, open and half-open intervals makes the interface complicated, however. The focus of closed-intervals is on intervals including both end-points and is intended to be used on records with length or duration information. My use cases are mostly sequences of annotated time intervals [*], parsed from time-stamped data. Against these sequences overlap-, coverage- and intersection queries are run using single intervals as query. The package contains many doctests. Testing builds on Henning Thielemann's doctest-extract [5] and doctest-exitcode-io [6] packages. closed-intervals is, after provenience [7], the second package in an effort to open-source my employer's entire Haskell codebase. We will gradually publish from general to problem-specific. Cheers, Olaf [1] https://hackage.haskell.org/package/closed-intervals [2] https://hackage.haskell.org/package/data-interval [3] https://hackage.haskell.org/package/IntervalMap [4] https://hackage.haskell.org/package/intervals [5] https://hackage.haskell.org/package/doctest-extract [6] https://hackage.haskell.org/package/doctest-exitcode-io [7] https://hackage.haskell.org/package/provenience [*] Since time types are fine-grained and a time point is an idealized concept, the question of end-point inclusion is not that relevant for time intervals. We do distinguish between intersection in end-points and proper intersection, though.

1 0

Implementing Dragon, Uber's data-integration tool for property graphs
by Jeffrey Brown 23 Mar '21

23 Mar '21

If your interests include any nonempty subset of Haskell, category theory and graphs, you might enjoy this. Online attendance is free. (For all I know in-person attendance is free too, if you live near SF area.) https://www.meetup.com/Category-Theory/events/nnrhgsyccfbhc -- Jeff Brown | Jeffrey Benjamin Brown LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown> | Github <https://github.com/jeffreybenjaminbrown> | Twitter <https://twitter.com/carelogic> | Facebook <https://www.facebook.com/mejeff.younotjeff> | very old Website <https://msu.edu/~brown202/>

1 0

Global Package Install
by A. Mc. 22 Mar '21

22 Mar '21

Hello, I am trying to add the package System.Random to be able to run it the same way Data.List or Data.Char, et cetera does in ghci and in doing a ghc command line build. I've tried using $ stack ghci --package random which I have to run every single time I want to load a module that imports anything from System.Random and I've already tried $ cabal install --lib random which only works with cabal, and I've used the command $ stack install random, which says 'cache populated' but if a restart and load a dependent module, still is not working for me. I've also tried to update the .yaml file by putting System.Random into the brackets is the sr directory, but this I'm guessing isn't what you're supposed to do as it doesn't work either. I'm using Cygwin on a Windows 10 operating system. Your assistance in this matter would be greatly appreciated. Thank you for your time.

11 16

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

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

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

21st Midlands Graduate School in the Foundations of Computing Science: Final Call for Participation
by Andrei Popescu 17 Mar '21

17 Mar '21

FINAL 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

Can eta-reduction of (\xs -> augment (flip (flip . foldr) xs)) typecheck?
by Viktor Dukhovni 17 Mar '21

17 Mar '21

With both `augment` and `foldr` from GHC.Base: augment :: (forall b. (a -> b -> b) -> b -> b) -> [a] -> [a] augment g = g (:) foldr :: (a -> b -> b) -> b -> [a] -> b ... The function: \xs -> augment (g xs) where g xs c z = foldr c z xs -- pointfree: g == flip (flip . foldr) typechecks (it is in fact just (++)) λ> let g xs c z = foldr c z xs λ> :t \xs -> augment (g xs) \xs -> augment (g xs) :: [a] -> [a] -> [a] Is it possible to explicitly type annotate some `g'` so that the function: (\xs -> (augment . g') xs) :: [a] -> [a] -> [a] is also just (++). That is, basically `g'` is the same as g, but with an explicit type signature that makes the type checker accept the eta-reduced composition? A completely naive attempt, with no type annotations yields: λ> let g xs c z = foldr c z xs λ> :t g g :: [a] -> (a -> b -> b) -> b -> b λ> :t (augment . g) <interactive>:1:2: error: • Couldn't match type: forall b. (a1 -> b -> b) -> b -> b with: (a -> b0 -> b0) -> b0 -> b0 Expected: ((a -> b0 -> b0) -> b0 -> b0) -> [a1] -> [a1] Actual: (forall b. (a1 -> b -> b) -> b -> b) -> [a1] -> [a1] • In the first argument of ‘(.)’, namely ‘augment’ In the expression: augment . g I haven't found any variant type signatures for "g" that make this go. I think this may require impredicative polymorphism, and so can't be done until perhaps QuickLook lands (don't know whether that'll be enough). -- Viktor.

1 0

Final Call for the early round of Papers for the Haskell Symposium 2021
by Hage, J. (Jurriaan) 16 Mar '21

16 Mar '21

Dear all, This is the final call for the early round of papers for the upcoming Haskell Symposium. Please forward to anyone that you believe might be interested. The deadline for this early round is March 19. Note that in May there is still the regular round of submissions. Apologies for receiving multiple copies of this announcement. Best regards, Jurriaan Hage Chair ================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2021 ** virtual ** Thu 26 -- Fri 27 August, 2021 http://www.haskell.org/haskell-symposium/2021/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2021 will be co-located with the 2021 International Conference on Functional Programming (ICFP). Due to COVID-19 it will take place **virtually** this year. Like last year, we will be using a lightweight double-blind reviewing process. See further information below. Different from last year is that we offer a new submission category: the tutorial. Details can be found below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * Tutorials, to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. A new submission category for this year's Haskell Symposium is the tutorial. Like with the experience report and the functional pearl, the key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details ================== Early and Regular Track ----------------------- The Haskell Symposium uses a two-track submission process so that some papers can gain early feedback. Strong papers submitted to the early track are accepted outright, and the others will be given their reviews and invited to resubmit to the regular track. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2021 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors' own related work should be in the third person (e.g., not "We build on our previous work" but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Tutorial: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Early track: Submission deadline: 19 March 2021 (Fri) Notification: 23 April 2021 (Fri) Regular track and demos: Submission deadline: 21 May 2021 (Fri) Notification: 23 June 2021 (Wed) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell21.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html) Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available) Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Edwin Brady University of St Andrews Koen Claessen Chalmers University of Technology Dominique Devriese Vrije Universiteit Brussel Andy Gill University of Kansas Jurriaan Hage (chair) Universiteit Utrecht Zhenjiang Hu Peking University Ranjit Jhala University of California Patricia Johann Appalachian State University Yukiyoshi Kameyama University of Tsukuba George Karachalias Tweag Ralf Laemmel University of Koblenz-Landau Daan Leijen Microsoft Research Ben Lippmeier Ghost Locomotion Neil Mitchell Facebook Alberto Pardo Universidad de la Republica, Uruguay Matt Roberts Macquarie University Janis Voigtlaender University of Duisburg-Essen Nicolas Wu Imperial College London If you have questions, please contact the chair at: j.hage(a)uu.nl ================================================================================

1 0

Re: [Haskell-cafe] Future of package cryptonite
by Kazu Yamamoto 16 Mar '21

16 Mar '21

Hi Ximin, Cc: haskell-cafe According to the mail archive[1], your messages are not delivered to haskell-cafe. So, I'm citing your response below. [1] https://mail.haskell.org/pipermail/haskell-cafe/2021-March/ --Kazu From: Ximin Luo <infinity0(a)pwned.gg> Subject: Re: [Haskell-cafe] Future of package cryptonite > Sven Panne: >> Am Mo., 15. März 2021 um 01:17 Uhr schrieb Kazu Yamamoto <kazu(a)iij.ad.jp <mailto:kazu@iij.ad.jp>>: >> >> We should also take care of "memory", "foundation" and "basement". >> No action is taken for over a month to >> https://github.com/haskell-foundation/foundation/pull/549 <https://github.com/haskell-foundation/foundation/pull/549> >> >> >> Somehow I'm getting more and more allergic to all these hasty unwarranted "I want to take over package XY" requests. The last release of cryptonite was less than 7 weeks ago, a PR for foundation was not merged within 5 weeks, etc. etc. For god's sake: If you are in such a hurry, just fork locally! Or even better: Give the maintainers a huge pile of $$$, most of them are doing their stuff in their spare time, so you can't expect SLAs where you would have to spend 5 digit sums as a company. Or you can fork visibly on e.g. GitHub under a different package name and let other people decide which variant to take. >> > > The cryptonite bugfix release in January is the *only* activity on the package for many months. As I understand from Kazu, Vincent has personally decided to quit, he just has not publicly announced it (nor made any other communications). > > So this bugfix release seems more of a "I guess I should really do the minimum to stop possible harm", rather than performing expected maintainer duties & making progress on the overall Haskell ecosystem. > >> "Taking over" a package can almost be seen as robbery from the point of view of the original author, and it is actively discouraging people to make their code Open Source. We should be much, much more sensitive in the Haskell community, I haven't seen such things in other language ecosystems. >> > > Haskell as an ecosystem is much smaller than other language ecosystems, and maintainers of key libraries like cryptonite going AWOL is unfortunately more common. Given that, it is expected to see more requests like this. > > Implicit in all of these requests is that, if the original maintainer restarts their normal maintainer activities, they can immediately re-exercise their maintainership activities and previous access. > > Package namespaces are a shared resource and its consequences affect everyone, and so "ownership" is not as simple as "who got it first". That is why we have a package takeover process in the first place. [1] One extreme case outside of Haskell would be the left-pad npm example. Nobody is taking away copyrights, licenses, or source code away from anyone; nobody has the power to do that. > > [1] https://wiki.haskell.org/Taking_over_a_package > >> Having said that, I think that a few projects are blocked by stack issues before they can support GHC 9.0. It would be great if things would be released more in lock-step, I dream of a world where a new GHC comes out in sync with cabal, stack, Stackage, Haskell language server etc. all supporting the new compiler. Other language ecosystems are lightyears ahead regarding this... :-/ >> >> Cheers, >> S. > > -- > GPG: ed25519/56034877E1F87C35 > https://github.com/infinity0/pubkeys.git

1 0

SML vs Haskell types
by Galaxy Being 16 Mar '21

16 Mar '21

Hello, This is my first post here, and it's an odd one, I'll admit. Basically, I'm trying to translate the material in *The Little MLer *to Haskell, the TLMLer being an excellent types workout. So in SML I have this datatype 'a shish = Bottom of 'a | Onion of 'a shish | Lamb of 'a shish | Tomato of 'a shish and this datatype rod = Dagger | Fork | Sword and then this SML function fun is_veggie (Bottom (x)) = true | is_veggie (Onion (x)) = is_veggie (x) | is_veggie (Lamb (x)) = false | is_veggie (Tomato (x)) = is_veggie (x) which has no problem handling tis is_veggie (Onion(Tomato(Bottom(Dagger)))) Now, in Haskell I've translated this (with minor alterations) to data Shish a = Holder a | Onion a (Shish a) | Lamb a (Shish a) | Tomato a (Shish a) data Rod = Dagger | Fork | Sword However, in Haskell these two expressions are different things entirely meal4 = Tomato Dagger (Onion Fork (Lamb Spear (Holder Fork))) meal5 = (Tomato (Onion (Lamb (Holder Fork)))) Here's my attempt at handling meal4 with a Haskell isVeggie isVeggie (Holder (sh)) = True isVeggie (Onion sh (sk)) = isVeggie sk isVeggie (Tomato sh (sk)) = isVeggie sk isVeggie (Lamb sh (sk)) = False This works for meal4, but not for meal5. And yet in the SML world their is_veggie handles (Onion(Tomato(Bottom(Dagger)))) just fine. TLMLer says Onion (Tomato (Bottom (Dagger))) belongs to the type rod shish, while in Haskell Onion (Tomato (Holder (Dagger))) is a bizarre nested beast due to the fact that the data constructor variable of Onion is Tomato (Holder (Dagger)) etc. etc. Can a single Haskell version of isVeggie handle both meal4 and meal5? No? I thought so. But then how would a separate Haskell version of isVeggie handle meal5 -- or is it just too weird? Also, but not critical, how could the Haskell isVeggie be done with guards, i.e., just like a consed list is matched on (x:xs) in the recursion case? I can see that 1:2:3:[] and Onion (Tomato (Bottom (Dagger))) are both conses, but the latter I don't know how to break out into head and tail for a guard case where the individual food items were not mentioned explicitly. IOW, this doesn't work isVeggieKebab :: Shish -> Bool isVeggieKebab Holder (sk) = True isVeggieKebab (shkb (sk)) | (shkb == Onion) || (shkb == Tomato) = isVeggieKebab sk | otherwise = False I'm feeling some doom and gloom about this project. Right at the start this seems to be an insurmountable difference between SML and Haskell type systems. Or I simply don't understand something fundamental here. LB

4 5

Re: [Haskell-cafe] Future of package cryptonite
by Kazu Yamamoto 16 Mar '21

16 Mar '21

Hello, We should also take care of "memory", "foundation" and "basement". No action is taken for over a month to https://github.com/haskell-foundation/foundation/pull/549 I cannot switch my main GHC version to 9.0 at this moment. --Kazu > Hello Haskell-cafe, > > I'm writing to discuss the future of the package cryptonite, including scenarios where it would be acceptable to take over the package - by me & Kazu (in CC), who already maintains hs-tls, and anyone else who is qualified and willing. > > The current maintainer Vincent (in CC) has been unresponsive to several attempts to contact him by email over the past several months, and is not responsive to PRs [1] on github. He is not entirely dormant, he has made a bugfix release in January, however otherwise he does not communicate. > > Based on [2] and some other hearsay, I understand that Vincent has "quit Haskell". The other maintainer, Oliver Chéron has also explicitly said that he has quit Haskell [3]. > > We have also attempted to contact other members of the haskell-crypto github group, however only one of them responded to say they don't feel they can make decisions for cryptonite. > > Under what time frame does the list think it would be acceptable to take over the package? And additionally, are there any other interested volunteers to co-maintain? (I do not want to be the main maintainer, due to more direct interests in other topics.) > > Best, > Ximin > > [1] https://github.com/haskell-crypto/cryptonite > [2] https://github.com/haskell-crypto/cryptonite/issues/330#issuecomment-670801… > [3] https://github.com/haskell-crypto/cryptonite/pull/323#issuecomment-701885924 > > -- > GPG: ed25519/56034877E1F87C35 > https://github.com/infinity0/pubkeys.git

5 4

Re: [Haskell-cafe] Future of package cryptonite
by Andrew Lelechenko 15 Mar '21

15 Mar '21

> Under what time frame does the list think it would be acceptable to take over the package? And additionally, are there any other interested volunteers to co-maintain? (I do not want to be the main maintainer, due to more direct interests in other topics.) If you do not want to be the main maintainer and do not have much interest in cryptography, then it sounds wrong to initiate a takeover. There is a procedure for non-maintainer uploads via Hackage Trustees, please file an issue at https://github.com/haskell-infra/hackage-trustees/issues <https://github.com/haskell-infra/hackage-trustees/issues>, linking a patched repository. > I cannot switch my main GHC version to 9.0 at this moment. It would be nice to audit that `cryptonite` is not vulnerable to https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html <https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html> Best regards, Andrew

1 0

Re: [Haskell-cafe] Property checks and PostgreSQL?
by Anthony Clayden 15 Mar '21

15 Mar '21

> PostgreSQL data base, Haskell back end, PureScript front end. And there is a fault somewhere in this stack: sometimes some items present in the data base do not make it to the front end. A small fortune in programmer hours has been spent ... Speaking purely from a SQL-and-stuff point of view, "programmer hours spent" sounds to me like a problem with nulls. Are any of your columns nullable? Are you sure they should be nullable? In particular are any of the columns in the keys nullable? Or any of the columns on which you're joining tables? (Perhaps a proper value in one table, but a null in the table it's supposed to equal?) How are you mapping between Haskell field values to/from nullable columns in the SQL? Is that mapping fool-proof? Is it consistent across different tables using what should be the same value? And in general: SQL nulls are an abomination; don't do that; do normalise your database schema to avoid nulls. AntC (35 years an SQL programmer, never trusted it)

1 0

Let's fight Int, Pt. 2
by Johannes Waldmann 15 Mar '21

15 Mar '21

Dear Cafe, it's bad to use Int where you really mean Nat, because this creates extra work (defensive programming, or mental gymnastics to prove that you don't need it) Another Int anti-feature is arithmetics with silent wrap-around - with respect to an unspecified modulus, as highlighted by a recent example: https://gitlab.haskell.org/ghc/ghc/-/issues/19500 What are the possibilities for a "checked Int"? (also, "checked Nat") A historical precedent is set by Ada http://archive.adaic.com/standards/83lrm/html/lrm-03-05.html#3.5.4 "The exception NUMERIC_ERROR is raised by the execution of an operation ... that cannot deliver the correct result" Another point in the design space is Rust: "Integer operators will panic when they overflow when compiled in debug mode." https://doc.rust-lang.org/reference/expressions/operator-expr.html?highligh… The Haskell standard https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-135000… says that "The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types are undefined;" so any program that relies on Int's wrap-around, is already broken. GHC's base library specifies "modulo 2^width" semantics for signed (Data.Int) and unsigned (Data.Word) integer types. Finally, about "fighting" - I guess it's more about strategies to cope with the present situation. - J.W.

2 1