March 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

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 31 Mar '21

31 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 30 Mar '21

30 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 29 Mar '21

29 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