- Haskell-Cafe - Haskell.org

1st CfP: SLE 2025 - 18th ACM SIGPLAN International Conference on Software Language Engineering
by Andrei Chis 10 Oct '24

10 Oct '24

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-particip…) 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(a)uni-rostock.de and vadim(a)grammarware.net)

1 0

Runtime selection on types while capturing a dictionary?
by Benjamin Redelings 09 Oct '24

09 Oct '24

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

3 3

Re: [Haskell-cafe] Runtime selection on types while capturing a dictionary?
by Olaf Klinke 08 Oct '24

08 Oct '24

> 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-t…

1 0

39th Agda Implementor's Meeting (AIM XXXIX) 25-30 Nov 2024 in Gothenburg
by Andreas Abel 20 Sep '24

20 Sep '24

---------------------------------------------------------------------- Agda Implementors' Meeting XXXIX Call for participation https://wiki.portal.chalmers.se/agda/Main/AIMXXXIX ---------------------------------------------------------------------- The 39th Agda Implementors' Meeting will take place in Gothenburg, Sweden, from Monday 25th to Saturday 30th November 2024. (This is our 20th anniversary of Agda meetings, the first took place in Fall 2004 in Gothenburg.) The meeting will consist of: * Presentations concerning theory, implementation, and use cases of Agda and other Agda-like languages. * Discussions around issues related to the Agda language. * Plenty of time to work in, on, under or around Agda, in collaboration with other participants. * A special session dedicated to the 20th anniversary of AIM. Attendance is free of charge, but a registration is warranted until 31st October 2024 (soft deadline). For information how to register check out https://wiki.portal.chalmers.se/agda/Main/AIMXXXIX Looking forward to seeing you in there! Andreas (on behalf of the AIM XXXIX organizing committee) -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www.cse.chalmers.se/~abela/

1 0

PhD position at KU Leuven
by Tom Schrijvers 16 Sep '24

16 Sep '24

KU Leuven invites applications for a PhD position in Prof. Tom Schrijvers' research team, exploring the interaction between multi-stage programming and computational effects. Ideal candidates hold a Master's in Computer Science, have a strong academic record, and a passion for programming languages like Haskell, type systems, and functional programming. We offer a 4-year scholarship, a dynamic research environment, and opportunities for international collaboration. Join us to push the boundaries of programming language theory! For more information see: https://www.kuleuven.be/personeel/jobsite/jobs/60384347?hl=nl&lang=nl

1 0

Call for Volunteers - Security Response Team
by Jose Calderon 04 Sep '24

04 Sep '24

The Security Response Team (SRT) is formally calling for applications to join the SRT. People from the Haskell community with information security experience are encouraged to apply. This is an opportunity to have a large impact on the practice of Haskell programming going forward. Since its inception, the SRT has had an outsized impact on the Haskell Ecosystem. I can say with confidence that the group conducts its business in an extremely professional and disciplined manner. If you have an interest in helping the team continue its mission, please apply! ## Security Response Team responsibilities The general responsibilities of the SRT are: - Manage the Haskell Security Advisory Database, on behalf of the Haskell community and the Haskell Foundation. - Triage and assess incoming security reports or proposed/candidate security advisories. - Assist reporters to determine CVSS scores and CWE values for confirmed security issues. - Communicate with package maintainers and the community to promote the timely resolution of reported security issues. - Ensure the security advisory data are useful for downstream security tooling. (Development of downstream tooling is not an SRT responsibility, but engaging with the developers is) - Report quarterly on the activities of the SRT and statistics/trends in new security issues. ## How can you help? - You can apply - If you don't want to apply but know someone who would be great, encourage them to apply. - Volunteers should have experience in one or more of the following areas: - web application security - information security incident response - vulnerability research and analysis - penetration testing - cryptography - authentication and identity management - governance, risk management and compliance (GRC) - secure application development - algorithms, data structures, and their role in DoS attacks - related disciplines ## Who is involved? The current membership of the SRT is: - Fraser Tweedale - Gautier Di Folco - Mihai Maruseac - Tristan de Cacqueray The team is hoping to gain 2-3 new members via this call for volunteers. ## How to apply Email `Fraser Tweedale <frase+hasksec(a)frase.id.au>` with subject "Haskell SRT Application". Include a brief overview of your background in security and the specific topics (e.g. from the list above) with which you have experience. ## Deadline Please submit your applications by end of day September 30th, 2024.

1 0

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

04 Sep '24

# TFP 2025 - Call for Papers (trendsfp.github.io) ## 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

Call for Participation - Haskell Bug Interviews
by Leonhard Applis 02 Sep '24

02 Sep '24

Dear Haskell Mailing List, we are looking for participants for a ~30 minute interview on bugs, debugging and bug-classification in Haskell. There is a big body of literature on this for e.g. Java, but Haskell might has its own challenges (or hidden similarities), and we hope to map out valuable research that helps practitioners. Your opinion really matters, and I want to encourage anyone to reach out to us even if you don't feel "experienced enough". We don't have a measure for what a real Haskell programmer must do, and if you are coming from a different paradigm and background your insights are very valuable too. The only requirement is to use Haskell regularly enough to encounter and fix bugs, preferably in contact with other humans. This research is currently conducted at the TU Delft and underlies its Data Protection and Ethics standards. Participants from Industry are particularly encouraged and it is possible to redact the transcript post-interview to ensure only things are shared you are comfortable sharing. We will not share interviews or transcripts - only excerpts anonymized and gathered in a codebook. Looking forward for all your Bugs! Best Leonhard Applis (L.H.Applis(a)tu-delft.nl , Leonhard.Applis(a)Protonmail.com) Razvan Nistor (rnistor(a)protonmail.com)

1 0

NFData instance for ForeignPtr
by Vanessa McHale 01 Sep '24

01 Sep '24

I see that deepseq/base have NFData instances for Ptr but not ForeignPtr. Is there a reason there can be no such instance? Cheers, Vanessa McHale

1 0

Speeding up trivial programs
by amindfv＠mailbox.org 24 Aug '24

24 Aug '24

I'm working on a small program that has to run many, many times, as quickly as possible (yes, it needs to be a standalone program). I've optimized it in many ways, but I seem to have a time floor, observable with "Hello, world" $ cat Hello.hs main = putStrLn "Hello world" $ ghc -O2 Hello.hs $ time ./Hello Hello world real 0m0.150s user 0m0.117s sys 0m0.032s The equivalent program in C takes only 0.002s (75x faster). What is taking the extra time? Is it the RTS "booting"? Is there any way to speed this up? Thanks, Tom

7 8