January 2021 - Haskell-Cafe

Do something about Cabal?
by Ignat Insarov 04 Jan '22

04 Jan '22

# Do something about Cabal? Hello. Cabal is the second most used tool in Haskell after GHC. It has many problems. It may be noticed that there is one and a half developers working on it. This is clearly not enough to address these problems. I propose that this is a good place to invest in. ### Problems I have in mind: * Poor communication, lack of open source development process. The whole Cabal–Stack schism appears to be an outcome of poor communication. One of the leading developers of Cabal is even banned from participation somewhere in Stack circles.[1] Personally, I reported several issues to Cabal and every single time it resulted in sadness. Observe a vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒ there are fewer contributors ⇒ core developers are overworked. I have no hard evidence but it appears that presently, more people that strive to improve the Haskell build experience are outside the Cabal cabal than are inside. * User experience is an afterthought. Cabal's user experience is horrifying. A collection of complaints is being compiled elsewhere.[2] There are also bugs being opened to Cabal because of this, requiring triage and therefore wasting the precious time of the few overworked developers. Stack is much more friendly — this shows by example that the user experience problem is not inherent and may be solved. It is ordinary to receive output like this: ``` % cabal run example-executable Warning: The package list for 'hackage.haskell.org' is 84 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: example-0.1.0.6 (user goal) [__1] next goal: opaleye (dependency of example) [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project config TODO requires ==0.6.7006.1) [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7) [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2, opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1, opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0, opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0, opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0, opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3, opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0, opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the previous version to fail: excluded by constraint '^>=0.7' from example) [__1] fail (backjumping, conflict set: example, opaleye) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: opaleye, example ``` There are so many things that are wrong here. Even a sneaky _«to do»_ remark. If you wonder, in this case the solution is to remove and re-generate `cabal.project.freeze`. Even the name of the program — it is actually _«cabal-install»_ — is incomprehensible, it should be re-branded to Cabal, which is how everyone calls it anyway. * Features are not being introduced. There is no reason for two build tools to exist. The killer feature of Stack — snapshots — should be supported by Cabal. Possibly Cabal itself should be refactored and split so that there are separate tools for packaging, version resolution and human interaction — I do not know. But certainly the way things are presently is a waste of developer effort and a source of confusion for everyone. ### My proposition, in particular. * Ask all the people that show compassion to the cause of a great Haskell build tool to unite and work together on a better Cabal. This includes the developers of Stack and everyone that expressed unhappiness with the current state of Cabal. These people should be seen as a blessing, not as an obstacle. * Put in place a clear process for contributing and decision making, so that it does not come down to the privileged opinion of one of the core developers. * Make a model of user experience that Cabal should conform to, and make conformance a priority. Surely there are among us people that know a thing or two about user experience — call for them to step forward. Every issue that stems from misunderstanding, re-assign to the model instead of closing. * Merge the support of Stackage snapshots into Cabal. Ask the core developers of Stack to join the effort. Transition from Stack to Cabal should be one well discoverable command that just works. I realize that this letter is largely an opinion piece. You can also see it as an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the present. I do not insist that my vision is the best. But the present reality is not the best vision either. I propose, foremost, that we work and fight for a better future. [1]: https://github.com/commercialhaskell/stackage/issues/4472 [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal

23 39

Re: [Haskell-cafe] How to do reversible parsing?
by Johannes Waldmann 11 Jul '21

11 Jul '21

Rendell and Ostermann, Invertible syntax descriptions, Haskell Symposium '10 https://doi.org/10.1145/1863523.1863525 https://hackage.haskell.org/package/invertible-syntax For the general background, see, e.g., Grohne and Voigtländer 2017 Formalizing semantic bidirectionalization ... https://doi.org/10.1016/j.jlamp.2016.04.002 And there's a workshop series on Bidirectional Transformations (from 2012 onwards) - J.

3 9

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

05 Feb '21

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

2 1

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

01 Feb '21

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

3 3

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

30 Jan '21

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

1 0

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

30 Jan '21

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

4 4

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

29 Jan '21

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

3 3

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

27 Jan '21

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

2 1

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

26 Jan '21

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

2 2

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

25 Jan '21

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

2 3