- Haskell-Cafe - Haskell.org

Haskell Ecosystem Workshop @ Zurihac
by Jose Calderon 08 Feb '24

08 Feb '24

Hello everyone, Much like last year, the Haskell Foundation is putting on a technical workshop co-located with Zurihac. Last year the focus was on GHC, this year we are changing the scope of the workshop in order to include tools that ‘fill out’ the Haskell and GHC development ecosystem, including: * Haskell Language Server * Cabal * Haskell Ecosystem Security * GHC The event will be held during the 2 days prior to Zurihac , 6-7 June, 2024. Please take this into account when planning your trip to Zurihac. The event's aim is to help folks interested in contributing to these tools get up to speed on the context, design, and workflow necessary in order to make contributions to these projects. We're asking our speakers to have 'good first issues' ready for volunteers to work on, and Zurihac itself will be a great time to dive in whilst still having access to the various maintainers. Additionally, the talks will be recorded as a form of documentation for these tools. We have a few speakers committed, but are still working on the overall program. Once we have the program finalized, we will open registration. We expect to have all speakers and talks finalized within the next few weeks. Just as last year, the event will have a modest registration fee in order to cover its costs and pay for the speakers to attend. If you have any suggestions on what tools/topics you would like to see represented, I’m happy to hear them. While this year’s program is mostly filled, it can help us know what to plan for future events like this. I hope to see you there!

1 0

Call for Participation: HAFDAL workshop, 3rd March in Edinburgh
by Rob Stewart 08 Feb '24

08 Feb '24

*Call for Participation* The Hardware Acceleration of Functional and Declarative Languages (HAFDAL) workshop on 3rd March is co-located with HPCA, CGO, CC and PPoPP in Edinburgh. Confirmed speakers are: *Reflections on compiling Haskell to Hardware*, Christiaan Baaij (QBayLogic) *The Cephalopode Project: Creating a low-power IoT device aimed at functional language execution*, Carl-Johan Seger (Chalmers University of Technology) *Prefetching in Functional Languages: a Hardware-Software Retrospective*, Sam Ainsworth (Research Consultant and University of Edinburgh) *Heron: A graph reduction processor with concurrent garbage collection*, Craig Ramsay (Heriot-Watt University) *PipelineC: Easier hardware description between RTL and HLS*, Julian Kemmerer (Deepwave Digital) *From Open Hardware Design to Silicon: Lessons From Some Big (Academic) Chips*, Jon Balkind (UC Santa Barbara) *BRAT: Compositional programming for hybrid quantum algorithms*, Craig Roy (Quantinuum) Workshop registration includes lunch, coffee and access to industry tutorials in the morning. https://haflang.github.io/workshops/hafdal24.html Best wishes, -- Rob Stewart Associate Professor Computer Science, Heriot-Watt University W: https://www.macs.hw.ac.uk/~rs46

1 0

PhD studentship in functional programming (closing date 9th Feb)
by Graham Hutton 02 Feb '24

02 Feb '24

Dear all, If you are interested in applying for the advertised PhD studentship in functional programming, please note that the closing date is now one week away (9th February). Best wishes, Graham +-----------------------------------------------------------+ Fully-Funded PhD Studentship Functional Programming Lab School of Computer Science University of Nottingham, UK http://tinyurl.com/fplab-phd Applications are invited for a fully-funded PhD studentship under the supervision of Prof Graham Hutton, starting on 1st October 2024. The successful applicant will join the Functional Programming Lab, an internationally-leading centre for programming language research. The topic for the studentship is open, but should relate to the research interests of Prof Hutton on the mathematics of program construction. The studentship forms part of the recently-funded EPSRC project on Semantics-Directed Compiler Construction, which seeks to develop new techniques for constructing certified compilers from semantics. The studentship is open to home and international students, is fully-funded for three and a half years, and includes a stipend of £18,622 per year and tuition fees. Applicants are expected to have a first-class Masters or Bachelors degree (or equivalent) in Computer Science and/or Mathematics, and an excellent ability and interest in the mathematical foundations of programming (topics such as logic and semantics), together with experience of programming in a functional language. Further information and advice for prospective applicants is available from http://tinyurl.com/369xwzc7. Funding for this studentship is already in place. To apply, please submit the following items by email to graham.hutton(a)nottingham.ac.uk: (1) a brief covering letter that describes your reasons for wishing to undertake a PhD and any ideas you have about potential topics; (2) a copy of your CV, including your actual or expected degree class(es) and results of all university examinations; (3) an example of your technical writing, such as a report or dissertation; (4) email addresses for two academic referees. Closing date for applications: Friday 9th February 2024. +-----------------------------------------------------------+ -- Professor Graham Hutton School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~pszgmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

CGO24 - Early-bird Deadline Registration
by L. Cicolini 31 Jan '24

31 Jan '24

ACM/IEEE International Symposium on Code Generation and Optimization (CGO 2024) Call for Participation - Early Bird Registration The International Symposium on Code Generation and Optimization (CGO) is a premier venue to bring together researchers and practitioners working at the interface of hardware and software on a wide range of optimization and code generation techniques and related issues. The conference spans the spectrum from purely static to fully dynamic approaches, and from pure software-based methods to specific architectural features and support for code generation and optimization. Registration (early-bird deadline: February 2) https://conf.researchr.org/attending/cgo-2024/registration Registration to CGO will give you full access to all co-located events on the day(s) selected (CC, PPoPP, HPCA). Detailed program: https://conf.researchr.org/program/cgo-2024/program-cgo-2024/ List of accepted papers: https://conf.researchr.org/info/cgo-2024/accepted-papers List of workshops/tutorials: https://conf.researchr.org/info/cgo-2024/workshops For more information, please visit the CGO conference website at https://conf.researchr.org/home/cgo-2024 *Copyright © 2024 CGO Conference, All rights reserved.* You are receiving this email because you have submitted to or attended CGO.

1 0

GHC Steering Committee Call for Nominations
by Adam Gundry 28 Jan '24

28 Jan '24

Dear Haskellers, The GHC Steering Committee is seeking nominations for new members. The committee scrutinizes, debates and eventually decides to accept or reject proposals to change the language or major features supported by GHC. Our processes are described in the GitHub repository where proposals are submitted (https://github.com/ghc-proposals/ghc-proposals) In particular, please have a look at the committee bylaws (https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst) We are looking for members who have the ability to: - understand GHC proposals (e.g. for new language extensions), - find holes and missing corner cases in the specifications, - foresee the interaction with other language or compiler features, - comment constructively and improve proposals through engagement with others, - judge the cost/benefit ratio of changes, and - come to a justifiable conclusion. Ideally, committee members should: - have substantial experience of writing or teaching Haskell; - have a track record of active contributions to the Haskell community; or - have expertise in language design and implementation, in either Haskell or related languages. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community. Even if you are uncertain whether your background qualifies you for the role, you are warmly encouraged to apply. The committee's work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at adam(a)well-typed.com by February 16th 2024, briefly summarising your background and relevant experience. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. Self-nominations are the norm. You can nominate someone else, but please obtain their explicit consent to do so. (We don't want to choose someone who turns out to be unable to serve.) On behalf of the committee, Adam Gundry -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

1 0

`queue` package take-over request
by Mitchell Rosen 24 Jan '24

24 Jan '24

Hi all, I'd like to take over the `queue` package, last updated 14 years ago, and marked "deprecated" on Hackage. I intend to replace it with a simple, clean implementation of Okasaki's "real time" (meaning O(1) worst-case operations) queue, which you can find implemented here: https://github.com/awkward-squad/queues I had originally named the package `queues` (with an s), but figured it would be better to repurpose the singular `queue` with something useful, if possible. Thanks! Mitchell

4 7

heads-up: tls v2.0.0
by Kazu Yamamoto 21 Jan '24

21 Jan '24

Hello guys, I'm planning to release the "tls" package v2.0.0 probably within one month. It removes TLS 1.0/1.1 and provides only TLS 1.2/1.3 with safe cipher suites according to recent RFCs and internet-drafts. This version does not change the default usage. But if you are using custom parameters, you might have to modify your code. This breaking change is *intentional* to notice users that they are using vulnerable versions and/or parameters. The attached is the current change log. --Kazu ## Version 2.0.0 * `tls` now only supports TLS 1.2 and TLS 1.3 with safe cipher suites. * Security: BREAKING CHANGE: TLS 1.0 and TLS 1.1 are removed. * Security: BREAKING CHANGE: all CBC cipher suite are removed. * Security: BREAKING CHANGE: RC4 and 3DES are removed. * Security: BREAKING CHANGE: DSS(digital signature standard) is removed. * Security: BREAKING CHANGE: TLS 1.2 servers require EMS(extended master secret) by default. * BREAKING CHANGE: the package is now complied with `Strict` and `StrictData`. * BREAKING CHANGE: Many data structures are re-defined with `PatternSynonyms` for extensibility. * BREAKING CHANGE: the structure of `SessionManager` is changed to support session tickets. * API: `handshake` can receive an alert of client authentication failure for TLS 1.3 [#463](https://github.com/haskell-tls/hs-tls/pull/463) * API: `bye` can receive NewSessionTicket for TLS 1.3 * Channel binding: `getFinished` and `getPeerFinished` are deprecated. Use `getTLSUnique` instead. * Channel binding: `getTLSExporter` and `getTLSServerEndPoint` are provided. [#462](https://github.com/haskell-tls/hs-tls/pull/462) * Refactoring: the monolithic `handshake` is divided to follow the diagram of TLS 1.2 and 1.3 for readability. * Refactoring: test cases are refactored for maintenability and readablity. `hspec` is used instead of `tasty`. * Code format: `fourmolu` is used as an official formatter.

5 18

Re: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns
by Olaf Klinke 20 Jan '24

20 Jan '24

> For functions types, there is only one equivalence class, because > there > is only one way to pattern-match a function. Observe that two > elements > can be distinguished by a set of patterns if and only if there is one > element in the pattern set that already distinguishes them. Do > pattern > synonyms refine the equivalence relation induced by ordinary > constructors? No. What I said is only true in the absence of view patterns. With view patterns, a pattern match is no longer guaranteed to terminate, since the viewing function could diverge on the value being matched. Consider -- diverges on infinite lists end :: [a] -> [a] end xs = case tl xs of [] -> [] (_:xs') -> end xs' pattern Finite <- (end -> []) isFinite :: [a] -> Bool isFinite xs = case xs of Finite -> True _ -> False Notice that isFinite is no longer a clopen but an open: It either returns True or diverges. Moreover, view patterns introduce fine- grained clopens on function spaces, like pattern Q <- (($ 4) -> 3) We must conclude that in the presence of the ViewPatterns extension, the equivalenve relation induced by pattern matching is: "x~y whenever there is no function v and no pattern P such that (v x) and (v y) can be distinguished by P." It should not be hard to prove that deciding coverage by view patterns such as Finite would solve the halting problem. Olaf

1 0

Parallel Haskell on an M2 Mac
by Dennis Raddle 20 Jan '24

20 Jan '24

I don't know a lot about parallel Haskell, so I'm wondering in general terms how that would work with my M2 Mac. I have a search task that's easily run in parallel. For example, I might map a function over a list, and each item's evaluation can run in parallel. On the M2 MacBook I have, there are 4 efficiency cores with 1 thread each, and 8 performance cores with 2 threads each. Is it fairly easy to use parallel Haskell to spread the task over these 20 possible threads? By any chance could I limit it to using the performance cores if that helps the speed? Thanks, Dennis

3 3

Re: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns
by Olaf Klinke 19 Jan '24

19 Jan '24

> > Should we open a feature request at Haddock? > > I think that would be a good idea. A cursory search suggests there's > no feature request already Done: https://github.com/haskell/haddock/issues/1625 I would also like to humbly suggest that the GHC devs consider my proof that pattern synonym completeness checks are decidable, thus improving the situation that caused this thread. I have a proof-of-concept implementation with a type signature like covers :: PatternMatch t => [Pattern t] -> Bool where type Pattern t = t -> Bool and PatternMatch is a type class much like Generic which derives instances for all Generic Rep types (except V1) plus function spaces and fixed points. What is left to do is to convert the GHC-internal pattern representation into (t -> Bool). Is that feasible? As I elaborated, that task ist quite mechanistic and could likely be done in Template Haskell. Olaf

1 0