- Haskell-Cafe - Haskell.org

[ANNOUNCE] GHC 9.8.3 is now available
by Ben Gamari 20 Oct '24

20 Oct '24

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

1 0

attpoarsec and recursive parsing
by PICCA Frederic-Emmanuel 18 Oct '24

18 Oct '24

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

1 0

Call for Proposals Now Open for Functional Conf 2025 (online)
by John Sinclair 17 Oct '24

17 Oct '24

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<https://confengine.com/conferences/functional-conf-2025/proposals?utm_mediu…> Submission deadline: 17 November 2024 Functional Conf is an online event running 24-25 January 2025. Learn more about the conference: https://functionalconf.com

1 0

POPL 2025 Call for Tutorials (deadline extended: Oct 25th, 2024)
by Ningning Xie 17 Oct '24

17 Oct '24

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(a)dtu.dk) and Robert Rand (rand(a)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(a)dtu.dk) and Robert Rand ( rand(a)uchicago.edu) or to the general chair Steve Zdancewic ( stevez(a)seas.upenn.edu)

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.12.1-alpha1 is now available
by Vanessa McHale 16 Oct '24

16 Oct '24

2 1

anyone using wxHaskell
by Zoran Bošnjak 15 Oct '24

15 Oct '24

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

3 7

Re: [Haskell-cafe] Runtime selection on types while capturing a dictionary?
by Benjamin Redelings 14 Oct '24

14 Oct '24

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.

2 1

Call for Contributions: BOB 2025 (Berlin, March 14 - Deadline Nov 15)
by Stefan Wehr 14 Oct '24

14 Oct '24

================================================================================ 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

1 0

Ideas for a master's thesis
by Jon Kristensen 11 Oct '24

11 Oct '24

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

2 1

[TFP 2025 2nd Call for Papers] 25th International Symposium on Trends in Functional Programming (Oxford, UK)
by Peter Achten 11 Oct '24

11 Oct '24

# 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-gu…) ## 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

1 0