- Haskell-Cafe - Haskell.org

[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 06 Apr '21

06 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 05 Apr '21

05 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