From jon at nejla.com Wed Oct 2 15:52:07 2024 From: jon at nejla.com (Jon Kristensen) Date: Wed, 2 Oct 2024 17:52:07 +0200 Subject: [Haskell-cafe] Ideas for a master's thesis Message-ID: Hi! I'm about to do a master's thesis in Software Engineering and I'm thinking about the possibility of doing something related to Haskell. I would like to apply (Bayesian) statistics and, ideally, conduct some kind of experiment. If you have any suggestions on topics, please let me know! Are there perhaps any particular challenges related to packages, dependencies, breakages or security vulnerabilities that I could take a look at? Is the PVP debate still ongoing, by the way? Back in 2016, when I started looking into what I could do as a thesis, I wrote the following in a thesis proposal: There is a (polarized) debate in the Haskell community about its package versioning policy (“PVP”), a variant of semantic versioning. Basically, the debate is centered around whether developers of Haskell packages should be “optimistic” or “pessimistic” in regards to breakages when introducing new versions of dependencies. Put differently, the debate is about how liberal or conservative developers should be when they set upper bound version restrictions for dependencies that have not been released yet. A liberal approach can result in a late discovery of a package breaking (possibly during compilation), and a conservative approach could result in constraints that cause the dependency solver not to find a set of dependencies that satisfies the version constraints (where one would have been possible and desirable). The objective for the study is to inform the PVP debate by developing a model that can be used to analyze why packages break when new versions of dependencies are released. The research question is: How can the handling of package dependencies in package systems using semantic versioning be changed to significantly reduce the problem of packages breaking? Thanks! 🙂 All the best, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.redelings at gmail.com Mon Oct 7 21:38:30 2024 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Mon, 7 Oct 2024 17:38:30 -0400 Subject: [Haskell-cafe] Runtime selection on types while capturing a dictionary? Message-ID: Hi, I'm new to Haskell, and I'm writing a class for evolutionary trees.  Since I'm new to Haskell, trying to encode information at the type level is new to me.  In C++ I'd use runtime checks to ask whether (for example) a tree is rooted.  Or I'd have the getRoot function return Maybe NodeID and then make the methods for checking if a branch points rootward throw an exception if the tree is unrooted. I'm trying to avoid doing this the C++ way, but this raises a lot of question.  Let me start with 2 of them: 1. Is there any advice on how to represent data structures that may or may not have a list of attributes? But what I have in Haskell right now looks like this:     data Graph (IntMap Node) (IntMap Edge)     data WithBranchLengths t = WithBranchLengths t (IntMap Double)     data WithLabels t l = WithLabels t (IntMap (Maybe l))     data Forest = Forest Graph     {- Assert that the Graph is a Forest -}     data WithRoots t = WithRoots t [NodeId]     data WithNodeTimes t = WithNodeTimes t (IntMap Double)     data WithBranchRates t = WithBranchRates t (IntMap Double)     data Tree = Tree Forest            {- Assert that the Forest is a Tree -} A tree with labels, roots, and branch lengths could have following types:     WithLabels (WithRoots (WithBranchLengths Tree)) Text     WithLabels (WithBranchLengths (WithRoots Tree)) Text     WithRoots (WithLabels (WithBranchLengths Tree) Text)     WithRoots (WithBranchLengths (WithLabels Tree Text))    .. etc etc.. The fact that there are multiple ways to represent the same thing is already not great.  Also, the fact that you can do WithBranchLengths (WithBranchLengths Tree) indicates that the construction of types should be obeying certain rules that are not expressed.  Only the outer WithBranchLengths is going to count, and there really should not be two of the same attribute. 2.  I'm wondering if it is possible to do run-time selection on whether a tree is rooted or not.  (I've considered trying to move all checks to the type-level, but this inhibits putting models with different properties into the same list -- see below) class IsGraph g where     ... class IsGraph g => IsDirectedGraph g where     isForward :: g -> EdgeId -> Bool class IsDirectedGraph g => IsDirectedAcyclicGraph g class IsGraph f => IsForest f where     type family Unrooted f     type family Rooted f     unroot :: f -> Unrooted f     makeRooted :: f -> Rooted f class (IsDirectedAcyclicGraph t, IsForest t) => HasRoots t where     isRoot :: t -> NodeId -> Bool     roots :: t -> [NodeId]     isRoot f n = isSource f n     roots f = filter (isRoot f) (getNodes f) At first I was thinking that since rooting is at the type level, then I can't do any runtime branching on whether a tree is rooted.  But then it occured to me that a GADT can package dictionaries with a constructor, so that in theory I could do something like: likelihood s t = if isEquilibriumReversible s then equilibriumReversibleLikelihood s t                  else case isRooted t of Unrooted -> error "tree must be rooted, since model is not reversible or not at equilibrium!"                                          Rooted   -> rootedTreeLikelihood s t It seems like this might work if I could make a GADT with a signature something like:         data MaybeRooted t = Unrooted | HasRoots t => Rooted           -- Q: should this use a forall type? In that case the Rooted constructor would package the HasRoots t dictionary needed to run the rootedTreeLikelihood function.  But I'm not sure how I would actually write the `isRooted` function that would construct the MaybeRooted t data type.  I've considered trying to encode the EquilibriumReversible predicate at the type level to avoid runtime checks, but that has the problem that I couldn't put models with different properties into the the same list of type [m]. So I guess the questions are: Q2a: is this a reasonable way of trying to do runtime selection on whether a tree is rooted? Q2b: how would I write the `isRooted t` function? Feedback much appreciated. -BenRI P.S. Haskell code is here: https://github.com/bredelings/BAli-Phy/tree/master/haskell From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Oct 7 22:13:43 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 7 Oct 2024 23:13:43 +0100 Subject: [Haskell-cafe] Runtime selection on types while capturing a dictionary? In-Reply-To: References: Message-ID: On Mon, Oct 07, 2024 at 05:38:30PM -0400, Benjamin Redelings wrote: > I'm new to Haskell, and I'm writing a class for evolutionary trees.  Since > I'm new to Haskell, trying to encode information at the type level is new to > me.  In C++ I'd use runtime checks to ask whether (for example) a tree is > rooted.  Or I'd have the getRoot function return Maybe NodeID and then make > the methods for checking if a branch points rootward throw an exception if > the tree is unrooted. I think I'd just do data AugmentedTree roots lengths labels = MkAugmentedTree { tree :: Tree, labels :: labels, roots :: roots, lengths :: lenghts } and then just do stuff like type FullyAugmentedTree = AugmentedTree [NodeId] (IntMap Double) (IntMap (Maybe l)) type PartiallyAugmentedTree = AugmentedTree [NodeId] () (IntMap (Maybe l)) For rootedness-independence I strongly recommend against any type class shenanigans. Instead you can do data PossiblyRootedTree lengths labels where RootedTree :: AugmentedTree [NodeId] lengths labels UnrootedTree :: AugmentedTree () lengths labels and then isRooted :: PossiblyRootedTree lengths labels -> Bool isRooted = \case RootedTree {} -> True UnrootedTree {} -> False (but `isRooted` is not really very useful compared to just pattern matching every where you need to know.) Tom From olf at aatal-apotheke.de Tue Oct 8 13:02:52 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 08 Oct 2024 15:02:52 +0200 Subject: [Haskell-cafe] Runtime selection on types while capturing a dictionary? Message-ID: <19ba641cea958efb1119bc522fb349752e9a75f9.camel@aatal-apotheke.de> > It seems like this might work if I could make a GADT with a signature > something like: > > data MaybeRooted t = Unrooted | HasRoots t => Rooted Yes, that is what GADTs can do for you. But as Tom said, avoid this if cou can. Incidentally, there is a pattern known as "trees that grow" [1] Where a skeleton type has rank-1 parameters that can switch on and off certain constructors. E.g. for a rooted tree you would provide an Identity parameter, for an unrooted tree provide a Const Void or Const () parameter. Small example: data Tree' root branch = Tree' (root [branch (Tree root branch)]) type UnrootedLabeled a = Tree' Identity ((,) a) type RootedLabeled r b = Tree' ((,) r) ((,) b) -- etc. As you observed, this can become confusing, if there are too many variants and the types you actually work with are just type aliases. The advantage is (a) no type classes, (b) you can have pattern-matching functions for a variety of different trees if they do not depend on patterns in the type parameters. > Also, the fact that you can do WithBranchLengths > (WithBranchLengths Tree) indicates that the construction of types > should > be obeying certain rules that are not expressed. Having several type parameters instead of the single t, where every parameter plays a single role, can aid in making rules clearer, but only a GADT may enforce them. There are other rules that only a dependently-typed language will be able to express. Finally, have you tried using one of the existing Haskell graph libraries as a starting point? It may save you a lot of boilerplate code. Olaf [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/trees-that-grow.pdf From anka.213 at gmail.com Wed Oct 9 07:33:30 2024 From: anka.213 at gmail.com (=?utf-8?Q?Andreas_K=C3=A4llberg?=) Date: Wed, 9 Oct 2024 09:33:30 +0200 Subject: [Haskell-cafe] Runtime selection on types while capturing a dictionary? In-Reply-To: References: Message-ID: > On 8 Oct 2024, at 00:14, Tom Ellis wrote: > data PossiblyRootedTree lengths labels where > RootedTree :: AugmentedTree [NodeId] lengths labels > UnrootedTree :: AugmentedTree () lengths labels Isn’t that invalid syntax? Wouldn’t you need either data PossiblyRootedTree lengths labels where RootedTree :: AugmentedTree [NodeId] lengths labels -> PossiblyRootedTree lengths labels UnrootedTree :: AugmentedTree () lengths labels -> PossiblyRootedTree lengths labels or simply (avoiding GADT syntax altogether): data PossiblyRootedTree lengths labels = RootedTree (AugmentedTree [NodeId] lengths labels) | UnrootedTree (AugmentedTree () lengths labels) From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Oct 9 07:40:35 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 9 Oct 2024 08:40:35 +0100 Subject: [Haskell-cafe] Runtime selection on types while capturing a dictionary? In-Reply-To: References: Message-ID: On Wed, Oct 09, 2024 at 09:33:30AM +0200, Andreas Källberg wrote: > > > On 8 Oct 2024, at 00:14, Tom Ellis wrote: > > data PossiblyRootedTree lengths labels where > > RootedTree :: AugmentedTree [NodeId] lengths labels > > UnrootedTree :: AugmentedTree () lengths labels > > Isn’t that invalid syntax? Wouldn’t you need either > > data PossiblyRootedTree lengths labels where > RootedTree :: AugmentedTree [NodeId] lengths labels -> PossiblyRootedTree lengths labels > UnrootedTree :: AugmentedTree () lengths labels -> PossiblyRootedTree lengths labels > > or simply (avoiding GADT syntax altogether): > > data PossiblyRootedTree lengths labels = > RootedTree (AugmentedTree [NodeId] lengths labels) > | UnrootedTree (AugmentedTree () lengths labels) Yes, you're right, thanks (and I'm not sure why I thought that required a GADT). Tom From chisvasileandrei at gmail.com Thu Oct 10 09:24:54 2024 From: chisvasileandrei at gmail.com (Andrei Chis) Date: Thu, 10 Oct 2024 11:24:54 +0200 Subject: [Haskell-cafe] 1st CfP: SLE 2025 - 18th ACM SIGPLAN International Conference on Software Language Engineering Message-ID: 18th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2025) 12-13 June 2025 Koblenz, Germany https://www.sleconf.org/2025/ https://x.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 18th ACM SIGPLAN International Conference on Software Language Engineering (SLE) which is devoted to the principles of software languages: their design, their implementation, and their evolution. The SLE 2025 conference will be co-located with STAF 2025 and hosted in Koblenz, Germany, on 12-13 June 2025. --------------------------- Important Dates --------------------------- * Abstract submission: Fri 7 Feb 2025 * Paper submission: Fri 14 Feb 2025 * Authors response period: Tue 1 Apr - Sat 5 Apr 2025 * Notification: Tue 15 Apr 2025 * Conference: Thu 12 June - Fri 13 June 2025 (co-located with STAF) All dates are Anywhere on Earth. --------------------------- Topics of Interest --------------------------- SLE covers software language engineering in general, rather than engineering a specific software language. Topics of interest include, but are not limited to: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral/executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches - AI-assisted language design and optimisation * Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages - Model-based testing - AI-assisted validation * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms - AI-assisted refactoring * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability, language and software product lines * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications * Synergies between Language Engineering and emerging/promising research areas - Generative AI in language engineering (e.g., AI-based language modelling, AI-driven code generation tools) - AI and ML language engineering (e.g., ML compiler testing, code classification) - Quantum language engineering (e.g., language design for quantum machines) - Language engineering for physical systems (e.g., CPS, IoT, digital twins) - Socio-technical systems and language engineering (e.g., language evolution to adapt to social requirements) --------------------------- Types of Submissions --------------------------- SLE accepts the following types of papers: * Research papers: These are “traditional” papers detailing research contributions to SLE. Papers may range from 6 to 12 pages in length and may optionally include 2 further pages of bibliography/appendices. Papers will be reviewed with an understanding that some results do not need 12 full pages and may be fully described in fewer pages. * New ideas/vision papers: These papers may describe new, unconventional software language engineering research positions or approaches that depart from standard practice. They can describe well-defined research ideas that are at an early stage of investigation. They could also provide new evidence to challenge common wisdom, present new unifying theories about existing SLE research that provides novel insight or that can lead to the development of new technologies or approaches, or apply SLE technology to radically new application areas. New ideas/vision papers must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. * SLE Body of Knowledge: The SLE Body of Knowledge (SLEBoK) is a community-wide effort to provide a unique and comprehensive description of the concepts, best practices, tools, and methods developed by the SLE community. In this respect, the SLE conference will accept surveys, essays, open challenges, empirical observations, and case study papers on the SLE topics. These can focus on, but are not limited to, methods, techniques, best practices, and teaching approaches. Papers in this category can have up to 20 pages, including bibliography/appendices. * Tool papers: These papers focus on the tooling aspects often forgotten or neglected in research papers. A good tool paper focuses on practical insights that will likely be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. They may optionally include an appendix with a demo outline/screenshots and/or a short video/screencast illustrating the tool. Workshops: Workshops will be organised by STAF. Please inform us and contact STAF 2025 organisers if you would like to organise a workshop of interest to the SLE audience. Information on how to submit workshops can be found on the STAF 2025 Website. --------------------------- Submission --------------------------- SLE 2025 has a single submission round for papers, including a mandatory abstract registration and a rebuttal phase, where all authors of research papers will have the possibility of responding to the reviews on their submissions. Authors of accepted research papers will be invited to submit artefacts. --------------------------- Format --------------------------- Submissions have to use the ACM SIGPLAN Conference Format “acmart” ( https://sigplan.org/Resources/Author/#acmart-format); please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template, and that the document class definition is `\documentclass[sigplan,anonymous,review]{acmart}`. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colours remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. Accordingly, SLE will follow the double-blind process. Author names and institutions must be omitted from submitted papers, and references to the authors’ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. The submission website is: https://sle25.hotcrp.com --------------------------- Concurrent Submissions --------------------------- Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy ( https://www.sigplan.org/Resources/Policies/Republication/). Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism ( https://www.acm.org/publications/policies/plagiarism-overview). Submissions that violate these policies will be desk-rejected. --------------------------- Policy on Human Participant and Subject Research --------------------------- Authors conducting research involving human participants and subjects must ensure that their research complies with their local governing laws and regulations and the ACM’s general principles, as stated in the ACM’s Publications Policy on Research Involving Human Participants and Subjects ( https://www.acm.org/publications/policies/research-involving-human-participants-and-subjects). If submissions are found to be violating this policy, they will be rejected. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning soundness, relevance, novelty, presentation, and replicability. New ideas/vision papers will be evaluated primarily concerning soundness, relevance, novelty, and presentation. SLEBoK papers will be reviewed on their soundness, relevance, originality, and presentation. Tool papers will be evaluated concerning relevance, presentation, and replicability. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review at the discretion of the PC chairs. For research papers, authors will get a chance to respond to the reviews before a final decision is made. --------------------------- Artefact Evaluation --------------------------- SLE will use an evaluation process to assess the quality of artefacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted research papers are invited to submit artefacts. --------------------------- Awards --------------------------- * Distinguished paper: Award for the most notable paper, as determined by the PC chairs based on the recommendations of the program committee. * Distinguished artefact: Award for the artefact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artefact evaluation committee. * Distinguished reviewer: Award for the programme committee member that produced the most useful reviews as assessed by paper authors. * Most Influential Paper: Award for the SLE 2015 paper with the greatest impact, as judged by the SLE Steering Committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. **AUTHORS TAKE NOTE**: The official publication date 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. --------------------------- Organisation --------------------------- * General chair: Görel Hedin, Lunds Universitet, Sweden * PC co-chair: Regina Hebig, Universität Rostock, Germany * PC co-chair: Vadim Zaytsev, Universiteit Twente, The Netherlands * Publicity chair: Andrei Chiş, feenk gmbh, Switzerland * Local chair: Ralf Lämmel, Universität Koblenz, Germany --------------------------- Contact --------------------------- For additional information, clarification, or answers to any questions, please get in touch with the program co-chairs (regina.hebig at uni-rostock.de and vadim at grammarware.net). -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Fri Oct 11 13:36:54 2024 From: P.Achten at cs.ru.nl (Peter Achten) Date: Fri, 11 Oct 2024 15:36:54 +0200 Subject: [Haskell-cafe] [TFP 2025 2nd Call for Papers] 25th International Symposium on Trends in Functional Programming (Oxford, UK) Message-ID: <03e479188988d324a992cf919dfffa37@cs.ru.nl> # TFP 2025 - 2nd Call for Papers (trendsfp.github.io) 26th International Symposium on Trends in Functional Programming 14-16 January 2025, Oxford, UK ## Important Dates Submission deadline (pre-symposium, full papers): Wed 13th Nov 2024 (AOE) Notification (pre-symposium, full papers): Wed 11th Dec 2024 Submission deadline (pre-symposium draft papers): Wed 11th Dec 2024 (AOE) Notification (pre-symposium draft papers): Mon 16th Dec 2024 Submission deadline (post-symposium review): Wed 19th Feb 2025 (AOE) Notification (post-symposium submissions): Wed 26th Mar 2025 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. This year, TFP will take place in-person at the University of Oxford, UK. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. Please be aware that TFP has several submission deadlines. The first, 13th November, is for authors who wish to have their full paper reviewed prior to the symposium. Papers that are accepted in this way must also be presented at the symposium. The second, 11th December, is for authors who wish to present their work or work-in-progress at the symposium first without submitting to the full review process for publication. These authors can then take into account feedback received at the symposium and submit a full paper for review by the third deadline, 19th February. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five paper categories. High-quality submissions are solicited in any of these categories: * Research Papers: Leading-edge, previously unpublished research work * Position Papers: On what new trends should or should not be * Project Papers: Descriptions of recently started new projects * Evaluation Papers: What lessons can be drawn from a finished project * Overview Papers: Summarizing work with respect to a trendy subject Papers must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your paper is within the scope of TFP, please contact the programme chair, Jeremy Gibbons. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, each year TFP also awards a prize for the best student paper. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are the paper's first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Submission is via EquinOCS (https://equinocs.springernature.com/service/tfp2025). Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be revised and resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these papers for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (up to 20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS Guidelines web site (https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines). ## Organizing Committee Jeremy Gibbons University of Oxford, UK Programme Chair Jason Hemann Seton Hall University, US Conference Chair Peter Achten Radboud University Nijmegen, NL Publicity Chair Marco T. Morazán Seton Hall University, US Steering Committee Chair ## Programme Committee Peter Achten Radboud University Nijmegen, NL Edwin Brady University of St Andrews, UK Laura Castro University of A Coruña, ES Youyou Cong Tokyo Institute of Technology, JP Paul Downen University of Massachusetts Lowell, US João Paulo Fernandes University of Coimbra, PT Ben Greenman University of Utah, US Jurriaan Hage Heriot-Watt University, UK Jason Hemann Seton Hall University, US Zhenjiang Hu Peking University, CN Hans-Wolfgang Loidl Heriot-Watt University, UK Kazutaka Matsuda Tohoku University, JP Zoe Paraskevopoulou Ethereum Foundation, US Alejandro Serrano 47 Degrees, ES Nick Smallbone Chalmers University, SE Alley Stoughton Boston University, US Wouter Swierstra Utrecht University, NL Niki Vazou IMDEA Software Institute, ES Marcos Viera Universidad de la República, UY Viktória Zsók Eötvös Loránd University of Sciences, HU -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Fri Oct 11 22:44:30 2024 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 11 Oct 2024 22:44:30 +0000 Subject: [Haskell-cafe] Ideas for a master's thesis In-Reply-To: References: Message-ID: <010f01927dc142ff-cc0b957c-29ac-4107-87ce-810214b1b759-000000@us-east-2.amazonses.com> Sure is quiet around here. Much of the action that used to take place on this list has moved to discourse.haskell.org ; I encourage you to repost your question there. Good luck with your thesis! Richard > On Oct 2, 2024, at 11:52 AM, Jon Kristensen wrote: > > Hi! > > I'm about to do a master's thesis in Software Engineering and I'm thinking about the possibility of doing something related to Haskell. > > I would like to apply (Bayesian) statistics and, ideally, conduct some kind of experiment. If you have any suggestions on topics, please let me know! > > Are there perhaps any particular challenges related to packages, dependencies, breakages or security vulnerabilities that I could take a look at? > > Is the PVP debate still ongoing, by the way? Back in 2016, when I started looking into what I could do as a thesis, I wrote the following in a thesis proposal: > > There is a (polarized) debate in the Haskell community about its package versioning policy (“PVP”), a variant of semantic versioning. Basically, the debate is centered around whether developers of Haskell packages should be “optimistic” or “pessimistic” in regards to breakages when introducing new versions of dependencies. Put differently, the debate is about how liberal or conservative developers should be when they set upper bound version restrictions for dependencies that have not been released yet. A liberal approach can result in a late discovery of a package breaking (possibly during compilation), and a conservative approach could result in constraints that cause the dependency solver not to find a set of dependencies that satisfies the version constraints (where one would have been possible and desirable). > > The objective for the study is to inform the PVP debate by developing a model that can be used to analyze why packages break when new versions of dependencies are released. > > The research question is: How can the handling of package dependencies in package systems using semantic versioning be changed to significantly reduce the problem of packages breaking? > > Thanks! 🙂 > > All the best, > Jon > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.redelings at gmail.com Mon Oct 14 14:19:56 2024 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Mon, 14 Oct 2024 09:19:56 -0500 Subject: [Haskell-cafe] Runtime selection on types while capturing a dictionary? In-Reply-To: <6d0c9543-e7d2-47d5-8b23-5362ed99fede@gmail.com> References: <6d0c9543-e7d2-47d5-8b23-5362ed99fede@gmail.com> Message-ID: <4e2fd2b1-3668-4f4e-b300-2498a36ebff1@gmail.com> On 10/9/24 10:11 AM, Benjamin Redelings wrote: > Interesting! And thanks.  I've been able to move the labels into the > Graph class, and just use () as the label type when I don't want > labels.  Somehow I was expecting a Haskell mailing list to recommend > something involving DataKinds. > > The other augmentations are a bit more tricky.  The tree can have > either a BranchLength augmentation OR a NodeTime augmentation, but not > both.  The NodeTime augmentation only makes sense when the tree is > rooted.  Additionally, it makes sense on rooted forests and directed > acyclic graphs.  When using the NodeTime augmentation, we can > CALCULATE the branch lengths as the time difference between the nodes > at the two ends of a branch.  This provides some motivation to make > the branchLength function polymorphic, so that some of the downstream > code can be agnostic as to whether the branch lengths are directly > augmented, or computed from NodeTimes.  And then there is also a > BranchRate augmentation that only makes sense if we have a NodeTime > augmentation. > > I think your ADT makes more sense than just creating a lot of > (AddAugmentationX ExtraInfo Graph) data types.  So, I'll have to think > how to do that. > > On the other hand, I would like to retain some polymorphism.  For > example, it would be nice to allow multiple tree representations. > Sometimes a generic graph is what you want, but in other cases the > tree-generation process makes a data structure like > >     data Tree = Leaf {parent :: Maybe Tree } | Internal { left:: Tree, > right:: Tree, parent:: (Maybe Tree)} > > more natural.  So, having an IsGraph *class* versus just a single > Graph data structure seems valuable. > > QUESTION: Given that, can you expand on what counts as a type-class > "shenanigan"?  I fully agree that the class structure and the data > type structure isn't very good yet.  (It was implemented in haste to > make something "just work".  The standard format for printing trees -- > Newick format -- really prints rooted trees, so I ended up creating a > 'type family Rooted t' to make a rooted tree type from an unrooted > tree type.  That seems very hacky.)  But I would like to retain some > generality across common features between NodeTime and BranchLength > augmented trees, as well as (perhaps) generality across different > implementations of Graph / Tree. > > QUESTION: For the constraint that a NodeTime tree should be rooted, do > you think I should encode this constraint at the data-type level, or > at the function level?  I was initially thinking of encoding this at > the data type level, so that you couldn't construct a tree with node > times that was not rooted. But I suppose one could simply make all the > functions that USE node-time trees require some kind of Rooted > constraint by calling a function like 'parent node'.  This would > decouple the Rooted/Unrooted augmentation from the BranchLength / > NodeTime / Nothing augmentation.  Thoughts? > > -BenRI > > > On 10/7/24 6:13 PM, Tom Ellis wrote: >> On Mon, Oct 07, 2024 at 05:38:30PM -0400, Benjamin Redelings wrote: >>> I'm new to Haskell, and I'm writing a class for evolutionary trees.  >>> Since >>> I'm new to Haskell, trying to encode information at the type level >>> is new to >>> me.  In C++ I'd use runtime checks to ask whether (for example) a >>> tree is >>> rooted.  Or I'd have the getRoot function return Maybe NodeID and >>> then make >>> the methods for checking if a branch points rootward throw an >>> exception if >>> the tree is unrooted. >> I think I'd just do >> >>      data AugmentedTree roots lengths labels = >>        MkAugmentedTree { >>          tree :: Tree, >>          labels :: labels, >>          roots :: roots, >>          lengths :: lenghts >>        } >> >> and then just do stuff like >> >>      type FullyAugmentedTree = >>          AugmentedTree [NodeId] (IntMap Double) (IntMap (Maybe l)) >>        type PartiallyAugmentedTree = >>          AugmentedTree [NodeId] () (IntMap (Maybe l)) >> >> For rootedness-independence I strongly recommend against any type >> class shenanigans.  Instead you can do >> >>      data PossiblyRootedTree lengths labels where >>          RootedTree :: AugmentedTree [NodeId] lengths labels >>          UnrootedTree :: AugmentedTree () lengths labels >> >> and then >> >>      isRooted :: PossiblyRootedTree lengths labels -> Bool >>      isRooted = \case >>         RootedTree {} -> True >>         UnrootedTree {} -> False >> >> (but `isRooted` is not really very useful compared to just pattern >> matching every where you need to know.) >> >> Tom >> _______________________________________________ >> 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. From stefan.wehr at gmail.com Mon Oct 14 15:47:36 2024 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Mon, 14 Oct 2024 17:47:36 +0200 Subject: [Haskell-cafe] Call for Contributions: BOB 2025 (Berlin, March 14 - Deadline Nov 15) Message-ID: ================================================================================ BOB Conference 2025 "What happens when we use what's best for a change?" https://bobkonf.de/2025/cfc.html Berlin, Mar 14 Call for Contributions Deadline: November 15, 2024 ================================================================================ You are actively engaged in advanced software engineering methods, solve ambitious problem with software and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions. Specifically: - advice on structure and presentation - review of talk slides Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, and speakers who are not able to attend the conference for financial reasons. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - "fancy types" (dependent types, gradual typing, linear types, ...) - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - program synthesis - next-generation IDEs - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be - … includeing rough ideas worth discussing. Presenters should provide the audience with information that is practically useful for software developers. Challenges ---------- Furthermore, we seek contributions on successful approaches for solving hard problems, for example: - bias in machine-learning systems - digital transformation in difficult settings - accessibiltity - systems with critical reliability requirements - ecologically sustainable software development We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) Organisation ------------ - Direct questions to konferenz at bobkonf dot de - Proposal deadline: November 15, 2024 - Notification: December 4, 2024 - Program: December 11, 2024 Submit here: https://pretalx.com/bob-2025/submit/ Program Committee ----------------- (more information here: https://bobkonf.de/2025/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoran.bosnjak at via.si Mon Oct 14 16:30:45 2024 From: zoran.bosnjak at via.si (=?UTF-8?Q?Zoran_Bo=C5=A1njak?=) Date: Mon, 14 Oct 2024 18:30:45 +0200 Subject: [Haskell-cafe] anyone using wxHaskell Message-ID: Dear haskell cafe, I have a problem with scrolledWindow inside notebook, when running with the latest version of wxHaskell. See the minimal example below, where the scrollbar is not shown (the same sample is OK on the wxHaskell version from few years ago). I would appreciate a suggestion how to make the scrollbar work again (a workaround if possible). I have also filed the issue on the wxHaskell project page. But the project does not look like being super actively maintained. https://codeberg.org/wxHaskell/wxHaskell/issues/48 Minimal example: module Main where import Graphics.UI.WXCore import Graphics.UI.WX gui :: IO () gui = do f <- frame [text := "Frame"] p <- panel f [] nb <- notebook p [] p1 <- scrolledWindow nb [ scrollRate := sz 20 20 ] texts <- mapM (\n -> staticText p1 [text := ("test" <> show n) ]) [1::Int ..20] set f [ layout := fill $ widget p , clientSize := sz 400 200 ] set p [ layout := fill $ tabs nb [ tab "tab1" $ container p1 $ column 5 (fmap widget texts) ] ] main :: IO () main = start gui regards, Zoran From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Oct 14 17:50:43 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 14 Oct 2024 18:50:43 +0100 Subject: [Haskell-cafe] Runtime selection on types while capturing a dictionary? In-Reply-To: <4e2fd2b1-3668-4f4e-b300-2498a36ebff1@gmail.com> References: <6d0c9543-e7d2-47d5-8b23-5362ed99fede@gmail.com> <4e2fd2b1-3668-4f4e-b300-2498a36ebff1@gmail.com> Message-ID: It's hard to know exactly what to suggest but I can offer some ideas. Firstly, you defined a tree like this: data Graph (IntMap Node) (IntMap Edge) data Forest = Forest Graph {- Assert that the Graph is a Forest -} data TreeViaGraph = Tree Forest {- Assert that the Forest is a Tree -} Then you said you wanted perhaps to also define graphs like this data TreeViaBranching = Leaf {parent :: Maybe Tree } | Internal { left:: Tree, right:: Tree, parent:: (Maybe Tree)} and wanted to be polymorphic over the type of graph. I probably won't be polymorphic the way you're thinking. Instead I'd just define data EitherSortOfTree = MkTreeViaGraph TreeViaGraph | MkTreeViaBranching TreeViaBranching Now you can define everything in terms of EitherSortOfTree. Doesn't that do what you want? You can also parametrize EitherSortOfTree so the presence of absence of certain sorts of annotations is observable at the type level. I would really suggest avoiding shenanigans with existential type classes, by which I mean wrapping them in GADTs. There are probably some cases where that's the right thing to do. I doubt yours is one such. If you really think it is then please come back with some additional info. Regarding the constraint that all node time trees should be rooted, then you can use this parametrization data EitherSortOfTree nodeTimes roots = MkTreeViaGraph (TreeViaGraph, nodeTimes, roots) | MkTreeViaBranching (TreeViaBranching, nodeTimes, roots) and define newtype NodeTimedRootedEitherSortOfTree = MkNodeTimedRootedEitherSortOfTree (IntMap Double) [NodeId] I wouldn't try to enforce the constraint that all node time trees should be rooted on the base type (EitherSortOfTree) itself. That seems like a higher level property that's better represented with a newtype. Hope that helps, Tom On Mon, Oct 14, 2024 at 09:19:56AM -0500, Benjamin Redelings wrote: > On 10/9/24 10:11 AM, Benjamin Redelings wrote: > > Interesting! And thanks.  I've been able to move the labels into the > > Graph class, and just use () as the label type when I don't want > > labels.  Somehow I was expecting a Haskell mailing list to recommend > > something involving DataKinds. > > > > The other augmentations are a bit more tricky.  The tree can have either > > a BranchLength augmentation OR a NodeTime augmentation, but not both.  > > The NodeTime augmentation only makes sense when the tree is rooted.  > > Additionally, it makes sense on rooted forests and directed acyclic > > graphs.  When using the NodeTime augmentation, we can CALCULATE the > > branch lengths as the time difference between the nodes at the two ends > > of a branch.  This provides some motivation to make the branchLength > > function polymorphic, so that some of the downstream code can be > > agnostic as to whether the branch lengths are directly augmented, or > > computed from NodeTimes.  And then there is also a BranchRate > > augmentation that only makes sense if we have a NodeTime augmentation. > > > > I think your ADT makes more sense than just creating a lot of > > (AddAugmentationX ExtraInfo Graph) data types.  So, I'll have to think > > how to do that. > > > > On the other hand, I would like to retain some polymorphism.  For > > example, it would be nice to allow multiple tree representations. > > Sometimes a generic graph is what you want, but in other cases the > > tree-generation process makes a data structure like > > > >     data Tree = Leaf {parent :: Maybe Tree } | Internal { left:: Tree, > > right:: Tree, parent:: (Maybe Tree)} > > > > more natural.  So, having an IsGraph *class* versus just a single Graph > > data structure seems valuable. > > > > QUESTION: Given that, can you expand on what counts as a type-class > > "shenanigan"?  I fully agree that the class structure and the data type > > structure isn't very good yet.  (It was implemented in haste to make > > something "just work".  The standard format for printing trees -- Newick > > format -- really prints rooted trees, so I ended up creating a 'type > > family Rooted t' to make a rooted tree type from an unrooted tree type.  > > That seems very hacky.)  But I would like to retain some generality > > across common features between NodeTime and BranchLength augmented > > trees, as well as (perhaps) generality across different implementations > > of Graph / Tree. > > > > QUESTION: For the constraint that a NodeTime tree should be rooted, do > > you think I should encode this constraint at the data-type level, or at > > the function level?  I was initially thinking of encoding this at the > > data type level, so that you couldn't construct a tree with node times > > that was not rooted. But I suppose one could simply make all the > > functions that USE node-time trees require some kind of Rooted > > constraint by calling a function like 'parent node'.  This would > > decouple the Rooted/Unrooted augmentation from the BranchLength / > > NodeTime / Nothing augmentation.  Thoughts? > > > > -BenRI > > > > > > On 10/7/24 6:13 PM, Tom Ellis wrote: > > > On Mon, Oct 07, 2024 at 05:38:30PM -0400, Benjamin Redelings wrote: > > > > I'm new to Haskell, and I'm writing a class for evolutionary > > > > trees.  Since > > > > I'm new to Haskell, trying to encode information at the type > > > > level is new to > > > > me.  In C++ I'd use runtime checks to ask whether (for example) > > > > a tree is > > > > rooted.  Or I'd have the getRoot function return Maybe NodeID > > > > and then make > > > > the methods for checking if a branch points rootward throw an > > > > exception if > > > > the tree is unrooted. > > > I think I'd just do > > > > > >      data AugmentedTree roots lengths labels = > > >        MkAugmentedTree { > > >          tree :: Tree, > > >          labels :: labels, > > >          roots :: roots, > > >          lengths :: lenghts > > >        } > > > > > > and then just do stuff like > > > > > >      type FullyAugmentedTree = > > >          AugmentedTree [NodeId] (IntMap Double) (IntMap (Maybe l)) > > >        type PartiallyAugmentedTree = > > >          AugmentedTree [NodeId] () (IntMap (Maybe l)) > > > > > > For rootedness-independence I strongly recommend against any type > > > class shenanigans.  Instead you can do > > > > > >      data PossiblyRootedTree lengths labels where > > >          RootedTree :: AugmentedTree [NodeId] lengths labels > > >          UnrootedTree :: AugmentedTree () lengths labels > > > > > > and then > > > > > >      isRooted :: PossiblyRootedTree lengths labels -> Bool > > >      isRooted = \case > > >         RootedTree {} -> True > > >         UnrootedTree {} -> False > > > > > > (but `isRooted` is not really very useful compared to just pattern > > > matching every where you need to know.) > > > > > > Tom > > > _______________________________________________ > > > 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. From ivanperezdominguez at gmail.com Tue Oct 15 01:20:16 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 14 Oct 2024 18:20:16 -0700 Subject: [Haskell-cafe] anyone using wxHaskell In-Reply-To: References: Message-ID: Hi Zoran, wxhaskell refuses to compile with GHC 8.6.5 (or a more modern version). I have not tried anything prior to 8.6.5. The last update to https://hackage.haskell.org/package/wx was over 7 years ago. The version of wxc on hackage won't compile with Cabal >= 2.2 because of a change to the signature of rawSystemStdInOut, which is needed during the configure step for the package. That's as far as I went; there could be other issues. If you are able to create a docker image that compiles everything inside and reproduces your error with the scrollbar, I can give it a try. There appears to have been an attempt at reviving the project: https://sourceforge.net/p/wxhaskell/bugs/, and people at Zurihac were working on it. I don't know what happened. Cheers, Ivan On Mon, 14 Oct 2024 at 09:31, Zoran Bošnjak wrote: > Dear haskell cafe, > I have a problem with scrolledWindow inside notebook, when running with > the latest version of wxHaskell. See the minimal example below, where > the scrollbar is not shown (the same sample is OK on the wxHaskell > version from few years ago). > > I would appreciate a suggestion how to make the scrollbar work again (a > workaround if possible). I have also filed the issue on the wxHaskell > project page. But the project does not look like being super actively > maintained. > > https://codeberg.org/wxHaskell/wxHaskell/issues/48 > > Minimal example: > > module Main where > import Graphics.UI.WXCore > import Graphics.UI.WX > > gui :: IO () > gui = do > f <- frame [text := "Frame"] > p <- panel f [] > nb <- notebook p [] > p1 <- scrolledWindow nb > [ scrollRate := sz 20 20 > ] > texts <- mapM (\n -> staticText p1 [text := ("test" <> show n) ]) > [1::Int ..20] > set f > [ layout := fill $ widget p > , clientSize := sz 400 200 > ] > set p > [ layout := fill $ tabs nb > [ tab "tab1" $ container p1 $ column 5 (fmap widget texts) > ] > ] > > main :: IO () > main = start gui > > regards, > Zoran > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Oct 15 06:14:23 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 15 Oct 2024 08:14:23 +0200 (CEST) Subject: [Haskell-cafe] anyone using wxHaskell In-Reply-To: References: Message-ID: <194e207a-91a8-dbb5-8c0d-f16810880610@henning-thielemann.de> On Mon, 14 Oct 2024, Ivan Perez wrote: > wxhaskell refuses to compile with GHC 8.6.5 (or a more modern version). > I have not tried anything prior to 8.6.5. It seems, the project has moved there: https://codeberg.org/wxHaskell/wxHaskell/ This code can be compiled with recent GHC versions and for instance with some Nix glue. From zoran.bosnjak at via.si Tue Oct 15 07:33:08 2024 From: zoran.bosnjak at via.si (=?UTF-8?Q?Zoran_Bo=C5=A1njak?=) Date: Tue, 15 Oct 2024 09:33:08 +0200 Subject: [Haskell-cafe] anyone using wxHaskell In-Reply-To: References: Message-ID: Hi Ivan, if you have nix, you could get the nix-shell environment from the actual project and copy over the sample file: git clone https://github.com/zoranbosnjak/vcr.git cd vcr nix-shell # wait for half of the internet to compile :) # create test.hs sample either by copy-paste from the email below # or from https://codeberg.org/wxHaskell/wxHaskell/issues/48 # once inside the nix shell, run the sample runhaskell test.hs I've never used docker for that purpose, but I will try to create it if you have any issues with the procedure above. Let me know. regards, Zoran On 2024-10-15 03:20, Ivan Perez wrote: > Hi Zoran, > > wxhaskell refuses to compile with GHC 8.6.5 (or a more modern > version). I have not tried anything prior to 8.6.5. > > The last update to https://hackage.haskell.org/package/wx was over 7 > years ago. The version of wxc on hackage won't compile with Cabal >= > 2.2 because of a change to the signature of rawSystemStdInOut, which > is needed during the configure step for the package. That's as far as > I went; there could be other issues. > > If you are able to create a docker image that compiles everything > inside and reproduces your error with the scrollbar, I can give it a > try. > > There appears to have been an attempt at reviving the project: > https://sourceforge.net/p/wxhaskell/bugs/, and people at Zurihac were > working on it. I don't know what happened. > > Cheers, > > Ivan > > On Mon, 14 Oct 2024 at 09:31, Zoran Bošnjak > wrote: > >> Dear haskell cafe, >> I have a problem with scrolledWindow inside notebook, when running >> with >> the latest version of wxHaskell. See the minimal example below, >> where >> the scrollbar is not shown (the same sample is OK on the wxHaskell >> version from few years ago). >> >> I would appreciate a suggestion how to make the scrollbar work again >> (a >> workaround if possible). I have also filed the issue on the >> wxHaskell >> project page. But the project does not look like being super >> actively >> maintained. >> >> https://codeberg.org/wxHaskell/wxHaskell/issues/48 >> >> Minimal example: >> >> module Main where >> import Graphics.UI.WXCore >> import Graphics.UI.WX >> >> gui :: IO () >> gui = do >> f <- frame [text := "Frame"] >> p <- panel f [] >> nb <- notebook p [] >> p1 <- scrolledWindow nb >> [ scrollRate := sz 20 20 >> ] >> texts <- mapM (\n -> staticText p1 [text := ("test" <> show n) >> ]) >> [1::Int ..20] >> set f >> [ layout := fill $ widget p >> , clientSize := sz 400 200 >> ] >> set p >> [ layout := fill $ tabs nb >> [ tab "tab1" $ container p1 $ column 5 (fmap widget >> texts) >> ] >> ] >> >> main :: IO () >> main = start gui >> >> regards, >> Zoran >> _______________________________________________ >> 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. From lemming at henning-thielemann.de Tue Oct 15 08:05:55 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 15 Oct 2024 10:05:55 +0200 (CEST) Subject: [Haskell-cafe] anyone using wxHaskell In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024, Zoran Bošnjak wrote: > I have a problem with scrolledWindow inside notebook, when running with > the latest version of wxHaskell. See the minimal example below, where > the scrollbar is not shown (the same sample is OK on the wxHaskell > version from few years ago). I can reproduce your example, see attached screenshot. Running on libwxgtk3.2. Is scrolledWindow intended to have the scrollbar included? I would simply add a scrollbar and connect it with the scrolledWindow. -------------- next part -------------- A non-text attachment was scrubbed... Name: wx-scroll-window.png Type: image/png Size: 16119 bytes Desc: URL: From zoran.bosnjak at via.si Tue Oct 15 08:26:19 2024 From: zoran.bosnjak at via.si (=?UTF-8?Q?Zoran_Bo=C5=A1njak?=) Date: Tue, 15 Oct 2024 10:26:19 +0200 Subject: [Haskell-cafe] anyone using wxHaskell In-Reply-To: References: Message-ID: Yes, the scrollbar is intended, but it's not there. Your sample shows exactly the problem. I am attaching the intended result (from the old wxHaskell version) and the actual result (from the latest wxHaskell version, the actual result is the same as yours). Do you have an idea how to modify the sample to show the scrollbar? regards, Zoran On 2024-10-15 10:05, Henning Thielemann wrote: > On Mon, 14 Oct 2024, Zoran Bošnjak wrote: > >> I have a problem with scrolledWindow inside notebook, when running >> with the latest version of wxHaskell. See the minimal example below, >> where the scrollbar is not shown (the same sample is OK on the >> wxHaskell version from few years ago). > > I can reproduce your example, see attached screenshot. Running on > libwxgtk3.2. > > Is scrolledWindow intended to have the scrollbar included? I would > simply add a scrollbar and connect it with the scrolledWindow. -------------- next part -------------- A non-text attachment was scrubbed... Name: frame1.png Type: image/png Size: 7910 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frame2.png Type: image/png Size: 8360 bytes Desc: not available URL: From lemming at henning-thielemann.de Tue Oct 15 08:30:38 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 15 Oct 2024 10:30:38 +0200 (CEST) Subject: [Haskell-cafe] anyone using wxHaskell In-Reply-To: References: Message-ID: <2e0ad08a-bae9-5b0d-270b-ef733ea56a4c@henning-thielemann.de> On Tue, 15 Oct 2024, Zoran Bošnjak wrote: > Yes, the scrollbar is intended, but it's not there. Your sample shows > exactly the problem. I am attaching the intended result (from the old > wxHaskell version) and the actual result (from the latest wxHaskell > version, the actual result is the same as yours). Do the two wxHaskell versions use the same wxwidgets version? There might be differences in wxwidgets releases. > Do you have an idea how to modify the sample to show the scrollbar? Either there is a flag to make it visible again, or it was intentionally removed and then I would add a scrollbar myself and connect it to the scrolledWindow. From zoran.bosnjak at via.si Tue Oct 15 08:46:41 2024 From: zoran.bosnjak at via.si (=?UTF-8?Q?Zoran_Bo=C5=A1njak?=) Date: Tue, 15 Oct 2024 10:46:41 +0200 Subject: [Haskell-cafe] anyone using wxHaskell In-Reply-To: <2e0ad08a-bae9-5b0d-270b-ef733ea56a4c@henning-thielemann.de> References: <2e0ad08a-bae9-5b0d-270b-ef733ea56a4c@henning-thielemann.de> Message-ID: <3a74861bbb0e4a77bf90d2cda09f92ed@via.si> > Do the two wxHaskell versions use the same wxwidgets version? > There might be differences in wxwidgets releases. Indeed, there might be something related to the version. Not sure how to check exactly what is included, but the wxhaskell README says: - old wxhaskell: against: wxWidgets (http://www.wxwidgets.org/) 2.9.3 up to and including 3.0.3 - new wxhaskell: Builds against: [wxWidgets](https://www.wxwidgets.org/) 3.2 > Either there is a flag to make it visible again, or it was > intentionally removed and then I would add a scrollbar myself and > connect it to the scrolledWindow. I would appreciate a code snippet, to show exactly how. From zubin at well-typed.com Wed Oct 16 11:51:10 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Wed, 16 Oct 2024 17:21:10 +0530 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.12.1-alpha1 is now available Message-ID: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1-alpha1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst Cheers, Zubin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From george.colpitts at gmail.com Wed Oct 16 19:52:44 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 16 Oct 2024 16:52:44 -0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.12.1-alpha1 is now available In-Reply-To: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> References: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> Message-ID: It worked for me on my M2 mac but only after uninstalling and reinstalling Command Line Tools. Hopefully the problem I had was unique to me. I got an error when I ran ./configure on my M2 mac: checking C++ standard library flavour... actest.cpp:1:10: fatal error: 'iostream' file not found 1 | #include | ^~~~~~~~~~ 1 error generated. configure: error: Failed to compile test program Following is the complete output I got checking for opt-17... no checking for opt-17.0... no checking for opt17... no checking for opt-16... no checking for opt-16.0... no checking for opt16... no checking for opt-15... no checking for opt-15.0... no checking for opt15... no checking for opt-14... no checking for opt-14.0... no checking for opt14... no checking for opt-13... no checking for opt-13.0... no checking for opt13... no checking for opt... opt checking opt version (18.1.8) is between 13 and 20... yes checking for clang-19... no checking for clang-19.0... no checking for clang19... no checking for clang-18... clang-18 checking clang-18 version (18.1.8) is between 13 and 20... yes configure: $CC is not gcc; assuming it's a reasonably new C compiler checking whether CC supports -no-pie... no checking whether CC supports flags passed by GHC when compiling via C... yes checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done checking whether ld64 requires -no_fixup_chains... yes checking whether ld64 requires -no_fixup_chains... yes checking whether ld64 requires -no_fixup_chains... yes checking whether ld64 requires -no_fixup_chains... yes checking whether the linker requires -no_warn_duplicate_libraries... yes checking whether the linker requires -no_warn_duplicate_libraries... yes checking whether the linker requires -no_warn_duplicate_libraries... yes checking whether ld supports response files... yes checking C++ standard library flavour... actest.cpp:1:10: fatal error: 'iostream' file not found 1 | #include | ^~~~~~~~~~ 1 error generated. configure: error: Failed to compile test program On Wed, Oct 16, 2024 at 8:51 AM Zubin Duggal wrote: > The GHC developers are very pleased to announce the availability > of the first alpha release of GHC 9.12.1. Binary distributions, source > distributions, and documentation are available at [downloads.haskell.org > ][]. > > > We hope to have this release available via ghcup shortly. > > GHC 9.12 will bring a number of new features and improvements, including: > > * The new language extension [OrPatterns] allowing you to combine > multiple > pattern clauses into one. > > * The [MultilineStrings] language extension to allow you to more easily > write > strings spanning multiple lines in your source code. > > * Improvements to the OverloadedRecordDot extension, allowing the > built-in > `HasField` class to be used for records with fields of non lifted > representations. > > * The [NamedDefaults] language extension has been introduced allowing > you to > define defaults for typeclasses other than `Num`. > > * More deterministic object code output, controlled by the > `-fobject-determinism` > flag, which improves determinism of builds a lot (though does not > fully do so) > at the cost of some compiler performance (1-2%). See #12935 for the > details > > * GHC now accepts type syntax in expressions as part of [GHC Proposal > #281]. > > * ... and many more > > A full accounting of changes can be found in the [release notes][]. > As always, GHC's release status, including planned future releases, can > be found on the GHC Wiki [status][]. > > We would like to thank GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell > Foundation, and other anonymous contributors whose on-going financial > and in-kind support has facilitated GHC maintenance and release > management over the years. Finally, this release would not have been > possible without the hundreds of open-source contributors whose work > comprise this release. > > As always, do give this release a try and open a [ticket][] if you see > anything amiss. > > > [release notes]: > https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html > [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status > [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1-alpha1 > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [OrPatterns]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > [MultilineStrings]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst > [GHC Proposal #281]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > [NamedDefaults]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst > > > Cheers, > Zubin > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Wed Oct 16 22:57:20 2024 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 16 Oct 2024 18:57:20 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.12.1-alpha1 is now available Message-ID: <42D560B6-8769-4004-AFB0-FD36C1B8E828@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 89166504e40f4869ea825dd70048017861ec8578.png Type: image/png Size: 2738 bytes Desc: not available URL: From jeffbrown.the at gmail.com Wed Oct 16 23:18:40 2024 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Wed, 16 Oct 2024 18:18:40 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.12.1-alpha1 is now available In-Reply-To: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> References: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> Message-ID: > * GHC now accepts type syntax in expressions as part of [GHC Proposal #281] I feel like you buried the lede :) Many thanks to everyone involved! On Wed, Oct 16, 2024 at 6:51 AM Zubin Duggal wrote: > The GHC developers are very pleased to announce the availability > of the first alpha release of GHC 9.12.1. Binary distributions, source > distributions, and documentation are available at [downloads.haskell.org > ][]. > > > We hope to have this release available via ghcup shortly. > > GHC 9.12 will bring a number of new features and improvements, including: > > * The new language extension [OrPatterns] allowing you to combine > multiple > pattern clauses into one. > > * The [MultilineStrings] language extension to allow you to more easily > write > strings spanning multiple lines in your source code. > > * Improvements to the OverloadedRecordDot extension, allowing the > built-in > `HasField` class to be used for records with fields of non lifted > representations. > > * The [NamedDefaults] language extension has been introduced allowing > you to > define defaults for typeclasses other than `Num`. > > * More deterministic object code output, controlled by the > `-fobject-determinism` > flag, which improves determinism of builds a lot (though does not > fully do so) > at the cost of some compiler performance (1-2%). See #12935 for the > details > > * GHC now accepts type syntax in expressions as part of [GHC Proposal > #281]. > > * ... and many more > > A full accounting of changes can be found in the [release notes][]. > As always, GHC's release status, including planned future releases, can > be found on the GHC Wiki [status][]. > > We would like to thank GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell > Foundation, and other anonymous contributors whose on-going financial > and in-kind support has facilitated GHC maintenance and release > management over the years. Finally, this release would not have been > possible without the hundreds of open-source contributors whose work > comprise this release. > > As always, do give this release a try and open a [ticket][] if you see > anything amiss. > > > [release notes]: > https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html > [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status > [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1-alpha1 > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [OrPatterns]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > [MultilineStrings]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst > [GHC Proposal #281]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > [NamedDefaults]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst > > > Cheers, > Zubin > _______________________________________________ > 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. -- Jeff Brown | Jeffrey Benjamin Brown LinkedIn | Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Oct 16 23:44:12 2024 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 16 Oct 2024 20:44:12 -0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.12.1-alpha1 is now available In-Reply-To: <42D560B6-8769-4004-AFB0-FD36C1B8E828@gmail.com> References: <42D560B6-8769-4004-AFB0-FD36C1B8E828@gmail.com> Message-ID: Thanks Vanessa, it seems you had the same workaround: " remove and reinstall XCode command-line tools." Zubin What OS were the install tests run on? I'm running on 15.0.1. I think 15.1 is coming at the end of the month around the same time as alpha 2, hopefully 15.1 will be accompanied by a new version of XCode command-line tools that resolves these issues. On Wed, Oct 16, 2024 at 7:58 PM Vanessa McHale wrote: > I encountered something similar, Apple had been majorly slacking. > > [image: 89166504e40f4869ea825dd70048017861ec8578.png] > > Cabal can't find C++ headers for digest/text on Mac (Sequoia) > > discourse.haskell.org > > > > > > On Oct 16, 2024, at 3:53 PM, George Colpitts > wrote: > >  > It worked for me on my M2 mac but only after uninstalling and reinstalling > Command Line Tools. > > Hopefully the problem I had was unique to me. I got an error when I ran > ./configure on my M2 mac: > > checking C++ standard library flavour... actest.cpp:1:10: fatal error: > 'iostream' file not found > 1 | #include > | ^~~~~~~~~~ > 1 error generated. > configure: error: Failed to compile test program > > Following is the complete output I got > > checking for opt-17... no > checking for opt-17.0... no > checking for opt17... no > checking for opt-16... no > checking for opt-16.0... no > checking for opt16... no > checking for opt-15... no > checking for opt-15.0... no > checking for opt15... no > checking for opt-14... no > checking for opt-14.0... no > checking for opt14... no > checking for opt-13... no > checking for opt-13.0... no > checking for opt13... no > checking for opt... opt > checking opt version (18.1.8) is between 13 and 20... yes > checking for clang-19... no > checking for clang-19.0... no > checking for clang19... no > checking for clang-18... clang-18 > checking clang-18 version (18.1.8) is between 13 and 20... yes > configure: $CC is not gcc; assuming it's a reasonably new C compiler > checking whether CC supports -no-pie... no > checking whether CC supports flags passed by GHC when compiling via C... > yes > checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and > CPPFLAGS... done > checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, > CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done > checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, > CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done > checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, > CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done > checking whether ld64 requires -no_fixup_chains... yes > checking whether ld64 requires -no_fixup_chains... yes > checking whether ld64 requires -no_fixup_chains... yes > checking whether ld64 requires -no_fixup_chains... yes > checking whether the linker requires -no_warn_duplicate_libraries... yes > checking whether the linker requires -no_warn_duplicate_libraries... yes > checking whether the linker requires -no_warn_duplicate_libraries... yes > checking whether ld supports response files... yes > checking C++ standard library flavour... actest.cpp:1:10: fatal error: > 'iostream' file not found > 1 | #include > | ^~~~~~~~~~ > 1 error generated. > configure: error: Failed to compile test program > > On Wed, Oct 16, 2024 at 8:51 AM Zubin Duggal wrote: > >> The GHC developers are very pleased to announce the availability >> of the first alpha release of GHC 9.12.1. Binary distributions, source >> distributions, and documentation are available at [downloads.haskell.org >> ][]. >> >> >> We hope to have this release available via ghcup shortly. >> >> GHC 9.12 will bring a number of new features and improvements, including: >> >> * The new language extension [OrPatterns] allowing you to combine >> multiple >> pattern clauses into one. >> >> * The [MultilineStrings] language extension to allow you to more easily >> write >> strings spanning multiple lines in your source code. >> >> * Improvements to the OverloadedRecordDot extension, allowing the >> built-in >> `HasField` class to be used for records with fields of non lifted >> representations. >> >> * The [NamedDefaults] language extension has been introduced allowing >> you to >> define defaults for typeclasses other than `Num`. >> >> * More deterministic object code output, controlled by the >> `-fobject-determinism` >> flag, which improves determinism of builds a lot (though does not >> fully do so) >> at the cost of some compiler performance (1-2%). See #12935 for the >> details >> >> * GHC now accepts type syntax in expressions as part of [GHC Proposal >> #281]. >> >> * ... and many more >> >> A full accounting of changes can be found in the [release notes][]. >> As always, GHC's release status, including planned future releases, can >> be found on the GHC Wiki [status][]. >> >> We would like to thank GitHub, IOG, the Zw3rk stake pool, >> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell >> Foundation, and other anonymous contributors whose on-going financial >> and in-kind support has facilitated GHC maintenance and release >> management over the years. Finally, this release would not have been >> possible without the hundreds of open-source contributors whose work >> comprise this release. >> >> As always, do give this release a try and open a [ticket][] if you see >> anything amiss. >> >> >> [release notes]: >> https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html >> [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status >> [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1-alpha1 >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [OrPatterns]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst >> [MultilineStrings]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst >> [GHC Proposal #281]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst >> [NamedDefaults]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst >> >> >> Cheers, >> Zubin >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 89166504e40f4869ea825dd70048017861ec8578.png Type: image/png Size: 2738 bytes Desc: not available URL: From xnningxie at gmail.com Thu Oct 17 21:35:06 2024 From: xnningxie at gmail.com (Ningning Xie) Date: Thu, 17 Oct 2024 17:35:06 -0400 Subject: [Haskell-cafe] POPL 2025 Call for Tutorials (deadline extended: Oct 25th, 2024) Message-ID: POPL 2025 CALL FOR TUTORIALS https://popl25.sigplan.org/track/POPL-2025-tutorials#Call-For-Tutorials The 52nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL 2025) will be held in Denver, United States. POPL provides a forum for the discussion of fundamental principles and important innovations in the design, definition, analysis, transformation, implementation, and verification of programming languages, programming systems, and programming abstractions. Tutorials for POPL 2025 are solicited on any topic relevant to the POPL community. We particularly encourage submissions of introductory tutorials that make the research presented at POPL more accessible to the participants. Tutorials will be held on Jan 19–21, 2025. The expected length of a tutorial is 3 hours, including questions and discussion (Q&A). *Submission details* Deadline for submission:* October 25th, 2024* Notification of acceptance: November 1st, 2024 A tutorial proposal should provide the following information: - Tutorial title - Presenter(s), affiliation(s), and contact information - 1-3 page description (for evaluation). This should include the objectives, topics to be covered, presentation approach, target audience, prerequisite knowledge, and if the tutorial was previously held, the location (i.e. which conference), date, and number of attendees if available. - 1-2 paragraph abstract suitable for tutorial publicity. - 1-paragraph biography suitable for tutorial publicity. Proposals must be submitted by email to Christoph Matheja (chmat at dtu.dk) and Robert Rand (rand at uchicago.edu) with the subject line "POPL 2025 Tutorial Proposal: [tutorial name]". The proposal should be attached as a PDF, docx, or txt file. *Further information* Any query regarding POPL 2025 tutorial proposals should be addressed to the co-located events chairs Christoph Matheja (chmat at dtu.dk) and Robert Rand ( rand at uchicago.edu), or to the general chair Steve Zdancewic ( stevez at seas.upenn.edu). -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at confengine.com Fri Oct 18 02:16:59 2024 From: john at confengine.com (John Sinclair) Date: Fri, 18 Oct 2024 02:16:59 +0000 Subject: [Haskell-cafe] Call for Proposals Now Open for Functional Conf 2025 (online) Message-ID: Attention all functional programming enthusiasts and experts! The Functional Conf 2025 Call for Proposals is now open, and it's a golden opportunity to share your insights and innovative applications of functional programming with a vibrant community of like-minded individuals. Whether you have tackled a tricky problem using functional programming, developed a unique application, or have experiences that could enlighten your peers, we want to hear from you! We're open to all topics related to functional programming. We are seeking deep technical topics that push the boundaries of what's possible with functional programming. Our commitment to diversity and transparency means all proposals will be public for community review. Is your proposal unique? Is it well-developed and ready-to-go? Then you've got what it takes! Submit your ideas and help us make Functional Conf 2025 an unforgettable experience. Submit your proposal today and help shape the future of functional programming! https://confengine.com/conferences/functional-conf-2025/proposals Submission deadline: 17 November 2024 Functional Conf is an online event running 24-25 January 2025. Learn more about the conference: https://functionalconf.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Oct 18 14:13:42 2024 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 18 Oct 2024 16:13:42 +0200 (CEST) Subject: [Haskell-cafe] attpoarsec and recursive parsing Message-ID: <590626674.46873257.1729260822553.JavaMail.zimbra@synchrotron-soleil.fr> Hello I have this type data MaskLocation = MaskLocation Text | MaskLocation'Tmpl Text | MaskLocation'Or MaskLocation MaskLocation deriving (Eq, Generic, Show) deriving anyclass (FromJSON, ToJSON) instance FieldEmitter MaskLocation where fieldEmitter (MaskLocation t) = t fieldEmitter (MaskLocation'Tmpl t) = t fieldEmitter (MaskLocation'Or l r) = fieldEmitter l <> " | " <> fieldEmitter r I just added the MaskLocation'Or constructor in order to allow writing "mymask.npy | mymask2.npy | ..." So my question how should I write the new parser here the parser for the MaskLocation without the MaskLocation'Or instance FieldParsable MaskLocation where fieldParser = do t ← takeText pure $ if "{scannumber:" `Data.Text.isInfixOf` t then MaskLocation'Tmpl t else MaskLocation t It seems to me that I need to consume all text until I find a '|', call the parser on the collected text and start again the process. But I do not have a clear idea of how to collect all the values once the process is over. If someone could help me design this parser, It would be great. thanks a lot Frederic From ben at well-typed.com Sun Oct 20 16:35:00 2024 From: ben at well-typed.com (Ben Gamari) Date: Sun, 20 Oct 2024 12:35:00 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.3 is now available Message-ID: <87bjzed972.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of GHC 9.8.3. Binary distributions, source distributions, and documentation are available on the [release] page. This release is primarily a bugfix release the 9.8 series. These include: * Significantly improve performance of code loading via dynamic linking (#23415) * Fix a variety of miscompilations involving sub-word-size FFI arguments (#25018, #24314) * Fix a rare miscompilation by the x86 native code generator (#24507) * Improve runtime performance of some applications of `runRW#` (#25055) * Reduce fragmentation when using the non-moving garbage collector (#23340) * Fix source links in Haddock's hyperlinked sources output (#24086) A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling! - Ben [release]: https://www.haskell.org/ghc/download_ghc_9_8_3.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.3/docs/users_guide/9.8.3-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ivanperezdominguez at gmail.com Wed Oct 23 13:57:41 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Wed, 23 Oct 2024 06:57:41 -0700 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions Message-ID: Hi Café I want to configure a cabal package (specifically, copilot-core) so that, when HPC is executed during testing with coverage enabled, it ignores certain definitions, for example: - Anything that is auto-generated (e.g., Show). - Data constructors and field accessors, for which GHC also defines functions automatically, are all assumed to work. - Proxy doesn't need to be WHNFed. I think there's a way to extract the tix file and modify it, but I'm trying to make this automated, and configure the cabal package so that the right options are passed by cabal to HPC. That way, even hackage will pick it up when it reports the coverage of our library. Any pointers? Thanks! Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Oct 24 08:37:51 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 24 Oct 2024 10:37:51 +0200 (CEST) Subject: [Haskell-cafe] Polymorphic equality in LiquidHaskell Message-ID: I want to assert statically assert equality of polymorphic parameters using LiquidHaskell. See for instance the following simplified Array type containing an array shape and for demonstration purposes only a single element: data Array sh a = Array {shape :: sh, element :: a} {-@ lift2 :: (Eq sh) => (a -> b -> c) -> arrA : Array sh a -> {arrB : Array sh b | shape arrA == shape arrB} -> Array sh c @-} lift2 :: (Eq sh) => (a -> b -> c) -> Array sh a -> Array sh b -> Array sh c lift2 f (Array sha a) (Array shb b) = if sha == shb then Array sha $ f a b else error "shapes mismatch" Running liquidhaskell yields Illegal type specification ... Sort Error in Refinement: {arrB : (Example.Equality.Array sh##a31s b##a31u) | Example.Equality.shape arrA == Example.Equality.shape arrB} Unbound symbol Example.Equality.shape I think the Haskell function (==) is not automatically lifted to LiquidHaskell's logic language. Is there another way to assert a kind of equality in LiquidHaskell? From ryan.gl.scott at gmail.com Thu Oct 24 14:56:58 2024 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 24 Oct 2024 10:56:58 -0400 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions Message-ID: Hi Ivan, Short answer: I'm not aware of a way to automate the process of excluding certain definitions from cabal-generated HPC coverage reports. Long answer: there is a way to manually modify HPC coverage reports using the hpc overlay command. Sadly, most the existing documentation on this command [1] is pretty sparse, so the only way I was able to discover this was by reading the original HPC paper [2] (in that paper, `hpc overlay` is called `hpc-makemtix`) and by finding an example of how to use `hpc overlay` in GHC's test suite [3]. To translate that example into prose: suppose you have the following program (hpc001.hs): main = print (const "Hello" "World") Here, the expression "World" is never evaluated, so by default HPC will claim that there is no coverage for it. This is pretty silly, however, so we'd like to instruct HPC not to warn about "World". To do so, first compile the example above with coverage enabled and run it: $ ghc -fhpc hpc001.hs $ ./hpc001 This should generate an hpc001.tix file. If you run `hpc markup hpc001.tix` and look at the resulting HTML report, you'll see that it warns about "World". Let's fix that. To do so, we have to define an HPC overlay file. The example given in GHC's test suite (sample_overlay.ovr) is: module "Main" { inside "main" { tick "\"World\"" on line 1; } } While I can't find a reference for the syntax that HPC overlay files use, this particular example is pretty self-explanatory: don't report about the expression "World" on line 1, which is found inside the `main` function in the `Main` module. In order to make use of this overlay file, we first have to convert it to a .tix file: $ hpc overlay sample_overlay.ovr > sample_overlay1.tix Then we have to combine it with our original .tix file: $ hpc combine hpc_sample.tix sample_overlay1.tix > total1.tix If we run `hpc markup total1.txt`, we now see that HPC no longer warns about "World", just as we'd hoped for. That is where my understanding of this feature ends, however. In particular, I'm not aware of a better way to generate overlay files (other than to write them by hand, which still feels somewhat laborious), and I'm not aware of any deeper integration with cabal so that these overlay files would be picked up and automatically applied (e.g., for reporting coverage on Hackage). Given that the HPC documentation for `hpc overlay` [1] labels this as an experimental feature, I'd be surprised if such tooling or integration existed. I agree that it would be cool if did, however. Best, Ryan ----- [1] https://hpc-bin.readthedocs.io/en/latest/hpc.html#hpc-overlay-and-hpc-draft [2] https://dl.acm.org/doi/abs/10.1145/1291201.1291203 [3] https://gitlab.haskell.org/ghc/ghc/-/blob/e39c8c993c1da534c5893ca418d1fa4cbb9e0a0a/testsuite/tests/hpc/simple/tixs/test.T#L44-50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Thu Oct 24 17:30:10 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Thu, 24 Oct 2024 10:30:10 -0700 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: References: Message-ID: Ryan -- thanks! Café, GHC Devs -- is anyone actively working on HPC? Thanks, Ivan PS. Putting David Binder in CC since he seems to have been one of the most active contributors as of lately. On Thu, 24 Oct 2024 at 07:57, Ryan Scott wrote: > Hi Ivan, > > Short answer: I'm not aware of a way to automate the process of excluding certain definitions from cabal-generated HPC coverage reports. > > Long answer: there is a way to manually modify HPC coverage reports using the hpc overlay command. Sadly, most the existing documentation on this command [1] is pretty sparse, so the only way I was able to discover this was by reading the original HPC paper [2] (in that paper, `hpc overlay` is called `hpc-makemtix`) and by finding an example of how to use `hpc overlay` in GHC's test suite [3]. To translate that example into prose: suppose you have the following program (hpc001.hs): > > main = print (const "Hello" "World") > > Here, the expression "World" is never evaluated, so by default HPC will claim that there is no coverage for it. This is pretty silly, however, so we'd like to instruct HPC not to warn about "World". To do so, first compile the example above with coverage enabled and run it: > > $ ghc -fhpc hpc001.hs $ ./hpc001 > > This should generate an hpc001.tix file. If you run `hpc markup hpc001.tix` and look at the resulting HTML report, you'll see that it warns about "World". Let's fix that. To do so, we have to define an HPC overlay file. The example given in GHC's test suite (sample_overlay.ovr) is: > > module "Main" { > inside "main" { > tick "\"World\"" on line 1; > } > } > > While I can't find a reference for the syntax that HPC overlay files use, this particular example is pretty self-explanatory: don't report about the expression "World" on line 1, which is found inside the `main` function in the `Main` module. In order to make use of this overlay file, we first have to convert it to a .tix file: > > $ hpc overlay sample_overlay.ovr > sample_overlay1.tix > > Then we have to combine it with our original .tix file: > > $ hpc combine hpc_sample.tix sample_overlay1.tix > total1.tix > > If we run `hpc markup total1.txt`, we now see that HPC no longer warns about "World", just as we'd hoped for. > > That is where my understanding of this feature ends, however. In particular, I'm not aware of a better way to generate overlay files (other than to write them by hand, which still feels somewhat laborious), and I'm not aware of any deeper integration with cabal so that these overlay files would be picked up and automatically applied (e.g., for reporting coverage on Hackage). Given that the HPC documentation for `hpc overlay` [1] labels this as an experimental feature, I'd be surprised if such tooling or integration existed. I agree that it would be cool if did, however. > > Best, > > Ryan > ----- > [1] https://hpc-bin.readthedocs.io/en/latest/hpc.html#hpc-overlay-and-hpc-draft > [2] https://dl.acm.org/doi/abs/10.1145/1291201.1291203 > [3] https://gitlab.haskell.org/ghc/ghc/-/blob/e39c8c993c1da534c5893ca418d1fa4cbb9e0a0a/testsuite/tests/hpc/simple/tixs/test.T#L44-50 > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sat Oct 26 10:27:11 2024 From: ben.franksen at online.de (Ben Franksen) Date: Sat, 26 Oct 2024 12:27:11 +0200 Subject: [Haskell-cafe] [ANN] Darcs 2.18.4 release Message-ID: <5f9fcb5f-25c2-4259-b94b-d2b61ad2471c@online.de> Hello Everyone On behalf of the Darcs [1] team, I would like to announce the release of Darcs 2.18.4 [2]. See [3] for the full release notes. The main reason for this release was to make it build with stack against stackage lts-22.34 on Linux. This in turn should hopefully make it re-appear in the Debian and Ubuntu GNU/Linux distros. Cheers Ben [1] https://darcs.net [2] https://hackage.haskell.org/package/darcs-2.18.4 [3] https://hackage.haskell.org/package/darcs-2.18.4/changelog From lemming at henning-thielemann.de Sat Oct 26 14:30:10 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 26 Oct 2024 16:30:10 +0200 (CEST) Subject: [Haskell-cafe] Type syntax in expressions (Was: [ANNOUNCE] GHC 9.12.1-alpha1 is now available) In-Reply-To: References: <2snpei5s6aapoanssr266h5idtgjcfsrojdiso6unuszkhdeih@7vyl6vfi2wzq> Message-ID: <29e47990-4f9f-d160-acbc-9b9edb840f7c@henning-thielemann.de> On Wed, 16 Oct 2024, Jeffrey Brown wrote: > > * GHC now accepts type syntax in expressions as part of [GHC Proposal #281] > > I feel like you buried the lede :) > > Many thanks to everyone involved! I understand that this is part of the Dependent Haskell roadmap. Is there something cool and useful that we can already do with this new extension? From olf at aatal-apotheke.de Sun Oct 27 14:46:19 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 27 Oct 2024 15:46:19 +0100 Subject: [Haskell-cafe] attpoarsec and recursive parsing Message-ID: Hi Frederic, Essentially, the '|' character acts like a binary operator in parsing arithmetical expression trees. To that end, the most ergonomic module I know of is provided by parsec [1], which has a port [2] to attoparsec. You have to decide whether the '|' operator should be left- or right- associative. That question vanishes if you decide to re-design your data type as data MaskLocation = MaskLocation Text | MaskLocation'Tmpl Text | MaskLocation'Or (NonEmpty MaskLocation) and use the sepBy1 combinator. Also you should think about whether and how to escape the separator Char inside ordinary MaskLocation strings. Olaf [1] https://hackage.haskell.org/package/parsec-3.1.17.0/docs/Text-ParserCombinators-Parsec-Expr.html [2] https://hackage.haskell.org/package/attoparsec-expr