- Haskell-Cafe - Haskell.org

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

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

06 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