- Haskell-Cafe - Haskell.org

Research fellow position at University of Bristol
by Meng Wang 28 May '22

28 May '22

Dear Haskellers, The programming languages group at Bristol is recruiting a research fellow to join our dynamic research group https://bristolpl.github.io/. Our research is ranked highly internationally and there is a strong focus on Haskell. We welcome functional programmers anywhere in the world to apply! (Another similar post at the level of research associate is also available.) https://www.bristol.ac.uk/jobs/find/details/?jobId=274355&jobTitle=Research… Meng Wang, PhD (Oxon) Senior Lecturer of Programming Languages Head of PL research group School International Director SCEEM (CS, EEE, EMath) School, University of Bristol PS. A selection of recent papers can be found below. They should give a good indication of the type of PL research conducted at Bristol: - Perera et al. (2022). Linked visualisations via Galois dependencies. POPL 2022. 10.1145/3498668 - Xie et al. (2022). Staging with Class. POPL 2022. 10.1145/3498723 - Yamaguchi et al. (2021). Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches. OOPSLA 2021. 10.1145/3485482 - Qian Z et al. (2021). Client-Server Sessions in Linear Logic. ICFP 2021. 10.1145/3473567 - Jones E & Ramsay S. (2021). Intensional Refinement Datatypes. POPL 2021. 10.1145/3445980 - Gratzer D et al. (2020). Multimodal Dependent Type Theory. LICS 2020. 10.1145/3373718.3394736 - Matsuda K & Wang M. (2020). Sparcl: A Language for Partially-Invertible Computation. ICFP 2020. 10.1145/3409000 - Zhang J et al. (2019). A Study of Bug Resolution Characteristics in Popular Programming Languages. IEEE Transactions on Software Engineering. 10.1109/TSE.2019.2961897 - Abate A et al. (2019). Automated Formal Synthesis of Provably Safe Digital Controllers for Continuous Plants. Acta Informatica, vol 57. 10.1007/s00236-019-00359-1 - Almeida et al. (2019). Machine-Checked Proofs for Cryptographic Standards: Indifferentiability of Sponge and Secure High-Assurance Implementations of SHA-3. CCS 2019. 10.1145/3319535.336321

1 1

Re: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.2.3 released
by Shayne Fletcher 27 May '22

27 May '22

there are already tickets covering this see https://gitlab.haskell.org/ghc/ghc/-/issues/21633 & -- https://gitlab.haskell.org/ghc/ghc/-/issues/21634. i have found that `allow-newer:true` and `resolver: nightly-2022-05-27` in `hadrian/stack.yaml` provides a workaround for the moment. On Fri, May 27, 2022 at 7:08 PM George Colpitts <george.colpitts(a)gmail.com> wrote: > Hi > > https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does > not install on macos, exists on 9.2.3 also. The workaround given in 21506 > works. Do you want a ticket for this? > > Thanks > George > > > On Fri, May 27, 2022 at 4:41 PM Zubin Duggal <zubin(a)well-typed.com> wrote: > >> >> The GHC developers are very happy to at announce the availability of GHC >> 9.2.3. Binary distributions, source distributions, and documentation are >> available at [`downloads.haskell.org`]( >> https://downloads.haskell.org/ghc/9.2.3) >> >> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html >> Blog Post: >> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html >> >> This release includes many bug-fixes and other improvements to 9.2.2 >> including: >> >> * A fix to a critical linking bug on Windows causing the 9.2.2 release >> to be unusable (#21196). >> >> * Numerous bug fixes for regressions and other issues in the >> typechecker (#2147, #21515, #20582, #20820, #21130, #21479). >> >> * Correctness bugs in the code generator and compiler backends (#21396, >> #20959, #21465). >> >> * Packaging fixes on many platforms (#20760, #21487, #21402). >> >> * Many others. See the [release notes][] for a full list. >> >> 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, Tweag I/O, Serokell, Equinix, SimSpace, 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, >> >> - Zubin >> >> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [release notes]: >> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.h… >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Shayne Fletcher

1 1

[Haskell] [ANNOUNCE] GHC 9.2.3 released
by Zubin Duggal 27 May '22

27 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html This release includes many bug-fixes and other improvements to 9.2.2 including: * A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196). * Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479). * Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465). * Packaging fixes on many platforms (#20760, #21487, #21402). * Many others. See the [release notes][] for a full list. 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, Tweag I/O, Serokell, Equinix, SimSpace, 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, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.h…

1 0

GHC.X.Hackage and GHC's release cycle
by Ben Gamari 27 May '22

27 May '22

Hello all, Recently in the Haskell Foundation's stability working group we have been discussing various practical issues that Haskell users and prospective adopters encounter around the ecosystem. During these discussions the topic of GHC's release schedule and the ecosystem's process migration to new GHC releases has come up repeatedly. To address some of these issues, I have opened a pair of somewhat-related HF Tech Proposals: * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the [head.hackage] infrastructure used to test GHC to enable use by library maintainers in porting and testing their libraries on new GHC releases. * the [tick-tock] release proposal seeks to provide better guidance to users needing long release lifecycles by designating every other release as a "long-term support" release, with 18-month backport window. Given the wide applicability of these proposals we hope to gather feedback from a broad swath of the community. If you have questions, opinions, or concerns on either, please leave your feedback on the respective proposal. We look forward to hearing from you. Thanks! - Ben [ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27 [head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/ [tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34

1 0

Should there be a haskell template for inclusion polymorphism in Haskell?
by Miao ZhiCheng 27 May '22

27 May '22

Hi Haskellers! Here are some of my thoughts about polymorphism in Haskell especially the inclusion polymorphism, with questions in the end. ~IGNORE THESE LHS BOILER PLATES~ > {-# LANGUAGE GADTs #-} > module Main where > import Unsafe.Coerce ( unsafeCoerce ) ~IGNORE THESE LHS BOILER PLATES~ * Classification of Polymorphism Let's assume that we are following the classification of polymorphism where there are four types of it: ?? Btw, does anyone have a good citation of this classification? I got it from all over the Internet instead: e.g https://www.tutorialspoint.com/types-of-polymorphisms-ad-hoc-inclusion-para… ** Overloading Polymorphism It allows function with same name to act in different manner for different types. ** Coercion Polymorphism Also called as casting sometimes. ** Inclusion Polymorphism Also called as subtyping. This allows to point derived classes using base class pointers and references. ** Parametric Polymorphism Also called early Binding, it allows to use same piece of code for different types. We can get it by using templates. ** Sub Classifications In terms of being ad-hoc or universal: - Overloading and Coercion are ad-hoc, - Inclusion and Parametric are universal. In terms of being compile-time vs run-time: - Coercion, Overloading, Parametric are all compile-time polymorphism, - while only Inclusion is run-time polymorphism. * Different Polymorphism in Haskell In terms of their counter parties in Haskell language: ** Overloading Polymorphismin Haskell I think type classes basically provides such overloading ad-hoc polymorphism. Some thinks so too: https://stackoverflow.com/questions/6636107/how-does-haskell-handle-overloa… > class Fooable a where > foo :: a -> Int > instance Fooable Int where > foo = id > instance Fooable Bool where > foo _ = 42 ** Coercion Polymorphism in Haskell I think Haskell has both `Coercible` & `unsafeCoerce` for handling representational equality in compile time. But I am not sure if c/c++ style of conercion between similar types such as int/float/double is something Haskell would want to inject these magic conversion code ever. ** Parametric Polymorphism in Haskell This is probably what Haskell is best at the most, demonstrated by the classic `map` function definition: > map' :: (a -> b) -> [a] -> [b] > map' _ [] = [] > map' f (x:xs) = f x : map' f xs Note that, one could also combine parametric and overloading together using constraints: > double :: Num a => a -> a > double x = x + x This `double` function is parametric, but constrained only to work with Num type classes, hence their implementations are overloaded. ** Inclusion Polymorphism in Haskell Ok, finally inclusion polymorphism is what I want to focus on and have some questions here. Before that, I do want to mention one observation, inclusion polymorphism probably is most likely the old OOP habits that die hard. For me at least, since I consider myself a recovering OOP run-time polymorphism addict, and my guess is that unless the use case do need run-time polymorphism, e.g. run-time execution layer abstration, it is often better off using other type of polymorphism to achieve the same result. And even Bjarne Stroustrup is flirting with the idea: [[https://www.youtube.com/watch?v=xcpSLRpOMJM][Bjarne Stroustrup - Object Oriented Programming without Inheritance - ECOOP 2015]] Let's think of translating this piece of pseudo OOP style code into haskell. ``` interface Num { Num (+)(Num a, Num b); Num (*)(Num a, Num b); Num abs(Num a); Num negate(Num a); Num signum(Num a); Num fromInteger(Integer); } interface Show { String show(Show a); } class AnyNum<T> implements Num, Show { // trivially implements Num Show interfaces } // Now we can use AnyNum<Int>, AnyNum<Double>, etc. through their Num or Show interfaces. ``` In Haskell though, thanks to the ability of having existential type, AnyNum is actually quite nice to write: > data AnyNum where > MkAnyNum :: (Num a, Show a) => a -> AnyNum But in order to use AnyNum like using interfaces in our pseudo code, we would have to write these boiler plates and in some cases using unsafeCoerce due to not using Typeable run-time information: > instance Num AnyNum where > (+) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b > (*) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b > abs (MkAnyNum a) = MkAnyNum . abs $ a > negate (MkAnyNum a) = MkAnyNum . negate $ a > signum (MkAnyNum a) = MkAnyNum . signum $ a > fromInteger = MkAnyNum . fromInteger > instance Show AnyNum where > show (MkAnyNum a) = show a Here is some test code that demonstrate how distressful unsafeCoerce is: > main = do > let a = MkAnyNum(1 :: Int) > let b = MkAnyNum(2 :: Double) > let c = MkAnyNum(3 :: Int) > print $ show $ a + b > print $ show $ a + c Outputs are: ``` λ> "4611686018427387905" "4" ``` Few observations: - If there is at most one occurance of the usage of the type class, there is no need for the unsafeCoerce. - Otherwise, unsafeCoerce is required, or otherwise those functions could be left to "undefined". So my central questions for discussions are: - Is inclusion polymorphism something we should use at all in Haskell? - These boiler plate code maybe better be generated using Haskell template instead, is there one already, or should there be one? Cheers, Miao

2 2

GHC 9.4.1-alpha2 now available
by Ben Gamari 24 May '22

24 May '22

The GHC developers are happy to announce the availability of the second alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1-alpha2 This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by Hadrian, it's possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, 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 testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.1-note…

2 1

ANN: haskell-links.org - searchable links db
by Simon Michael 21 May '22

21 May '22

Hello Haskell friends, Recently I said this on reddit: > There's no way these very frequent reddit and chat requests for learning materials can capture all the existing resources. There are too many, and folks who know where they are get burned out reposting them. There have been many attempts to gather them, haskell.org/documentation being the most obvious, but none of them have fully succeeded. We could really do with some more systematic, scalable (crowd-sourced, lightweight) approach. Then I experimented and set up https://haskell-links.org . This is version 1, providing: - A searchable read-only view of the Haskell links collected by lambdabot, the popular #haskell IRC bot. - A redirector/link shortener/memory aid, for jumping to any of these links via their short ID. Eg: https://haskell-links.org/doc <https://haskell-links.org/doc> https://haskell-links.org/books <https://haskell-links.org/books> https://haskell-links.org/ghc-guide <https://haskell-links.org/ghc-guide> - Collected links to other Haskell search tools, making this a fast way to get to anywhere in Haskelldom. After contemplation and discussion on #haskell, I believe version 2 should allow web editing and use its own database. But I wanted to share this one as it's a nice simple setup. I hope you might find useful ! Help is welcome, see README. Best, -Simon

2 2

[ANN]: simfin 1.0.0 - Simple financial data API wrapper
by Owen Shepherd 21 May '22

21 May '22

Hello everyone, I've released a small library that wraps the SimFin (https://simfin.com/) API. SimFin collates and organises financial data, and provides a nice little web API which provides historical prices, ratios, financial statement extracts, etc. Hackage link: https://hackage.haskell.org/package/simfin-1.0.0 Enjoy, - Owen

1 0

[template haskell] Sharing names between constructors and types
by Patrick L Redmond 20 May '22

20 May '22

Hello Haskell Cafe, When can a type not share the name of a constructor? Defining a type and a constructor with the same name, manually, as follows, seems to be acceptable: data F = F | T data T However, if the type is generated by Template Haskell, it is no longer acceptable, as follows: voidType :: Name -> DecsQ voidType n = do d <- dataD (return []) n [] Nothing [] [] return [d] In a separate module: data F = F | T $(voidType 'T) This will result in a "Multiple declarations of ‘T’" error. Is this expected? Thank you, Patrick

2 2

Package takeover request for rapid
by Markus Läll 19 May '22

19 May '22

Hi I would like to take over https://hackage.haskell.org/package/rapid The author of the package Ertugrul Söylemez, once an active member of the community perhaps best known for netwire, passed away in 2018. [1] The work required for the package thus far, and for which I've kept a fork for, is to bump version bounds as GHCs progress. [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 -- Markus Läll

5 7