- Haskell-Cafe - Haskell.org

What is the exponential version of dependently-typed Vector and Tensor?
by Johannes Riecken 15 Jul '22

15 Jul '22

I noticed that the definitions of Vector and Tensor have a parallel structure. Vector is an ornamentation of the Peano natural numbers, and Tensor is the parallel construction with multiplication and the multiplicative identity, except that the factors are stored in a list instead of directly multiplying, so that the dependent typing can ensure that the number of elements in the tensor is indeed equal to the product of these factors. (To make it more parallel, the Nat in Vector could be replaced with a list of ones.) ```haskell {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits import Data.Kind import Numeric.Natural import Data.Proxy data Vector (n :: Nat) a where Nil :: Vector 0 a Cons :: a -> Vector n a -> Vector (n + 1) a data Tensor :: forall n. Vector n Nat -> Type -> Type where Scalar :: a -> Tensor Nil a Dimension :: Vector n (Tensor d a) -> Tensor (Cons n d) a ``` That made me wonder what the exponential version with functions would look like and if that is a useful concept, too, or one that also exists in maths? As going from Vector to Tensor isn't completely mechanical, I had trouble figuring out myself how to go from Tensor to the next higher data structure. Cheers, Johannes

1 0

stack and package candidates
by Henning Thielemann 15 Jul '22

15 Jul '22

In a project my stack.yaml contains this line: - url: https://hackage.haskell.org/package/foobar-0.0/candidate/foobar-0.0.tar.gz This works, but if I update the foobar release candidate then Stack will not notice and stick to the old version. How can I invalidate or remove the cached foobar version?

1 0

Folding nested foldables -- Known pattern?
by Ivan Perez 12 Jul '22

12 Jul '22

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi cafÃ© TL;DR: In Copilot, we have an ad-hoc notion of a nestable data structure that can be folded into a list. I'm trying to rely on standard classes as much as possible. Is there a known class to capture the idea of folding nested data structures (e.g., transitive foldable?) [...] Content analysis details: (5.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ivanperezdominguez[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.2680] 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

2 1

mastered Haskell and need a new challenge???
by Anand, Christopher 11 Jul '22

11 Jul '22

1 0

Call for Reviewers APLAS 2022 Artifact Evaluation Committee
by Arpita Dutta 01 Jul '22

01 Jul '22

Dear all, The /20th Asian Symposium on Programming Languages and Systems/ (APLAS'22) is going to be holding its first /Artifact Evaluation Committee/ (AEC). The artifact evaluation process aims to promote, share, and catalogue the research artifacts of papers accepted to the APLAS research track. We are looking for motivated researchers at all academic stages (Ph.D. Students, Researchers, Lecturers, & Professors) to join us on the inaugural APLAS'22 AEC. The self-nomination form is available at: https://forms.gle/rJREG9DiFQHegZmD9 To nominate other people please use the following form: https://forms.gle/KFiQYLjELMsEjGLp8 As a committee member, your primary responsibility will be to review artifacts submitted by authors of accepted papers and ensure that the artifact is a faithful representation of the accepted paper's results. This will involve interacting with some tooling provided by the authors, check if the results of the main paper are consistent with the claims in the paper, and are also reproducible for researchers to come. APLAS will use a three-phase artifact review process: Kick-The-Tyres; Review the Artifact; and Iron-out-the-Wrinkles. Reviewing guidance for committee members will be made available once the committee has been formed. We will close nominations on: Friday 08 July 2022 (AOE) and notify the selected committee members on: Friday 15 July 2022 (AOE) We expect most of the reviewing process to be performed between 22nd August 2022 and 19th September 2022. We expect each artifact to take around eight hours to review and we will look to assign each reviewer three to four reviews. For each artifact, we will assign a Lead Reviewer to lead the reviewing process. Salient information about the reviewing process can be found online: https://2022.splashcon.org/track/aplas-2022-aec#Reviewer-Information<https://2022.splashcon.org/track/aplas-2022-aec#Reviewer-Information> Come join us to improve the quality of research in our field! Thanks Arpita Dutta and Jan de Muijnck-Hughes APLAS'22 AEC Co-Chairs. This call was adapted from the PLDI'22 AEC Call for Nominations.

1 0

Where does η-equivalence stop?
by Hécate 30 Jun '22

30 Jun '22

Hi Café! I was wondering if anyone knew of a centralised list of occurrences where GHC Haskell stops upholding η-equivalence. I am interested in both type changes and operational semantics. So far I've collected the following things: * Rank-2 types * Monomorphism restriction * The presence of seq * Non-pedantic bottoms One source is the GHC Manual¹, and Neil Mitchell pointed me to the list of bugs and limitations of HLint². If you have other examples, or explanations of the mechanisms at play here, I would be very interested, and intend to upstream those in the GHC manual. Cheers, Hécate [¹] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#e… [²] https://github.com/ndmitchell/hlint#bugs-and-limitations -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

4 4

Munich Haskell Meeting, 2022-06-28 @ 19:30
by Leah Neukirchen 26 Jun '22

26 Jun '22

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 28 at Hirschgarten (Biergarten, self-service area) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we'll look out for you. It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jun-2022/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

GHC 9.4.1-alpha3 now available
by Ben Gamari 24 Jun '22

24 Jun '22

The GHC developers are happy to announce the availability of the third 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-alpha3). 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 our Hadrian build system, 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, 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 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… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha3/docs/users_guide/9.4.1-note…

1 0

A pattern does not admit a type signature.
by Ignat Insarov 23 Jun '22

23 Jun '22

Hello Café! I cannot understand why the following code does not compile. ```Haskell {-# LANGUAGE UnicodeSyntax #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} module Arity where import GHC.TypeNats data Vektor length value where Sektor ∷ value → Vektor length value → Vektor (1 + length) value Mektor ∷ Vektor 0 value pattern (:>) ∷ value → Vektor length value → Vektor (1 + length) value pattern value :> values = Sektor value values infixr 5 :> ``` The error: ``` • Could not deduce: length1 ~ length from the context: (1 + length) ~ (1 + length1) bound by a pattern with constructor: Sector :: forall value (length :: Natural). value -> Vector length value -> Vector (1 + length) value, in a pattern synonym declaration at Arity.hs:16:27-45 Expected: Vector length value Actual: Vector length1 value ‘length1’ is a rigid type variable bound by a pattern with constructor: Sector :: forall value (length :: Natural). value -> Vector length value -> Vector (1 + length) value, in a pattern synonym declaration at Arity.hs:16:27-45 ‘length’ is a rigid type variable bound by the signature for pattern synonym ‘:>’ at Arity.hs:15:16-70 • In the declaration for pattern synonym ‘:>’ • Relevant bindings include values :: Vector length1 value (bound at Arity.hs:16:40) | 16 | pattern value :> values = Sector value values | ^^^^^^ ``` If I omit the pattern's type signature, the code compiles. What is going on?

4 4

Onward! Papers 2022 - CfP
by Andreea Costea 21 Jun '22

21 Jun '22

*** Onward! Papers 2022 Call for Papers *** Onward! is a premier multidisciplinary conference focused on everything to do with programming and software: including processes, methods, languages, communities and applications. Onward! is more radical, more visionary and more open than other conferences to ideas that are well-argued but not yet proven. We welcome different ways of thinking about, approaching and reporting on programming language and software engineering research. Onward! Papers is looking for grand visions and new paradigms that could make a big difference in how we will one day build software. But it is not looking for research-as-usual papers—conferences like OOPSLA are the place for that. Those conferences require rigorous validation such as theorems or empirical experiments, which are necessary for scientific progress, but which typically preclude discussion of early-stage ideas. Onward! papers must also supply some degree of validation because mere speculation is not a good basis for progress. However, Onward! accepts less rigorous methods of validation such as compelling arguments, exploratory implementations, and substantial examples. The use of worked-out examples to support new ideas is strongly encouraged. https://2022.splashcon.org/track/splash-2022-Onward-papers The submission deadline is July 10th, 2022 AOE.

1 0