- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Mystery: constructor type applications differ from signatures
by Ryan Scott 29 Oct '22

29 Oct '22

I'm inclined to believe that this is a bug in the way that GHC typechecks type applications in patterns. Can you file a GHC issue about this? Ryan

2 1

Mystery: constructor type applications differ from signatures
by Tom Ellis 29 Oct '22

29 Oct '22

I can't understand the different results from three versions of almost exactly the same function. The only difference is whether I bind type variables using type application or with a type signature. In each function isMaybeF, isMaybeG and isMaybeH below I bind three type variables f, g and h: AppK @_ @f @_ t (Proxy @g :: Proxy h) f, g and h ought to be just three different ways of binding exactly the same type. To my surpise, using them gives different results. The only difference between isMaybeF, isMaybeG and isMaybeH is the type variable I apply to `FromType`. I get a type error when I use a variable that was bound by a type application (f or g). The variable that was bound by a type signature (h) works as expected. It seems that when using f or g the type checker is too eager and looks at `FromType @f` (respectively g), decides that f must be of the form `Type -> Type`, a constraint which it can't satisfy at the site of the `AppK` pattern match, so it fails. When using h, by contrast, it seems to be able to wait to dispatch that constraint until it has seen `IsType`. Subsequently I discovered a simpler example with similar behaviour, except the type checker succeeds for g as well as h. What is going on here? (This all originally arose from my investigations into https://github.com/haskell/core-libraries-committee/issues/99#issuecomment-…) Tom {-# LANGUAGE GADTs #-} {-# LANGUAGE LambdaCase #-} -- | Requires GHC >= 9.2 and the issue appears in both 9.2 and 9.4 module Puzzle where import Data.Kind (Type) import Data.Typeable (eqT, Proxy(Proxy)) import Type.Reflection (Typeable, (:~:) (Refl)) -- | @FunRep (f b)@ witnesses that @b :: Type@. data FunRep a where AppK :: forall (k :: Type) (f :: k -> Type) (b :: k). IsType k -> Proxy f -> FunRep (f b) -- | @IsType k@ witnesses that @k ~ Type@. data IsType k where IsType :: IsType Type data FromType where FromType :: forall (f :: Type -> Type). FromType -- Could not deduce: k ~ * isMaybeF :: forall (a :: Type). FunRep a -> FromType isMaybeF = \case AppK @_ @f @_ t (Proxy @g :: Proxy h) -> case t of IsType -> FromType @f -- Could not deduce: k ~ * isMaybeG :: forall (a :: Type). FunRep a -> FromType isMaybeG = \case AppK @_ @f @_ t (Proxy @_ @g :: Proxy h) -> case t of IsType -> FromType @g -- Works fine isMaybeH :: forall (a :: Type). FunRep a -> FromType isMaybeH = \case AppK @_ @f @_ t (Proxy @_ @g :: Proxy h) -> case t of IsType -> FromType @h {-# LANGUAGE GADTs #-} {-# LANGUAGE LambdaCase #-} -- | Requires GHC >= 9.2 and the issue appears in both 9.2 and 9.4 module Puzzle2 where import Data.Kind (Type) import Data.Typeable (eqT, Proxy(Proxy)) import Type.Reflection (Typeable, (:~:) (Refl)) -- | @FunRep (f b)@ witnesses that @b :: Type@. data FunRep a where AppK :: forall k (b :: k). IsType k -> Proxy k -> FunRep b -- | @IsType k@ witnesses that @k ~ Type@. data IsType k where IsType :: IsType Type data FromType where FromType :: forall (b :: Type). FromType -- Works fine isMaybeF :: forall k (a :: k). FunRep a -> FromType isMaybeF = \case AppK @_ @f t (Proxy @_ @g :: Proxy h) -> case t of IsType -> FromType @f -- Works fine isMaybeG :: forall k (a :: k). FunRep a -> FromType isMaybeG = \case AppK @_ @f t (Proxy @_ @g :: Proxy h) -> case t of IsType -> FromType @g -- Works fine isMaybeH :: forall k (a :: k). FunRep a -> FromType isMaybeH = \case AppK @_ @f t (Proxy @_ @g :: Proxy h) -> case t of IsType -> FromType @h

1 1

Re: [Haskell-cafe] Updating the description of the mailing list?
by Douglas McIlroy 25 Oct '22

25 Oct '22

> Could the description be changed to simply be the first sentence? > "This mailing list is for the discussion of topics related to Haskell." Yes. Like definitions in a modern dictionary, it tells how the list is actually used rather than how some ancient authority thought it ought to be. Doug

1 0

Updating the description of the mailing list?
by Bryan 25 Oct '22

25 Oct '22

At https://mail.haskell.org/mailman/listinfo/haskell-cafe, the description states: This mailing list is for the discussion of topics related to Haskell. The volume may at times be high, as the scope is broader than the main Haskell mailing list. Discussions on the Haskell mailing list which have drifted off topic, or are only of interest to a small number of subscribers, will be asked to move to Haskell-Cafe. This implies that Haskell-Cafe is a place for off-topic discussions. In practice, haskell(a)haskell.org is unused and haskell-cafe(a)haskell.org *is* the Haskell mailing list. Could the description be changed to simply be the first sentence? "This mailing list is for the discussion of topics related to Haskell." --- This request comes from an effort to point potential new contributors to Haskell resources. Specifically, I'm editing https://gitlab.haskell.org/ghc/ghc/-/wikis/mailing-lists-and-irc. I wanted to add a link to haskell-cafe. While sanity-checking the URL, I read the description of the list and got momentarily confused: Should I actually be subscribed to haskell@ instead? But then after checking the archives, I remembered why I unsubscribed from that list many years ago. If it was confusing for me, I assume it would be confusing for newcomers as well. -Bryan

1 0

[ANN] - Hugs for MacOS (x86) - via Nix Flakes
by Justin Bailey 24 Oct '22

24 Oct '22

I spent some time with the last public release of the Hugs sources, making them compile on a modern Mac (x86 chipset). I used Nix's flakes feature to manage the build and install. If you'd like to run the hugs interpreter directly using the flake, just type: `nix run github:m4dc4p/hugs#hugs` If you'd like to execute a Haskell file, try: `nix run github:m4dc4p/hugs <file.hs>` Or alternately: `nix run github:m4dc4p/hugs#runhugs <file.hs>` (That is, `runhugs` is the default app provided by the flake.) See the README at https://github.com/m4dc4p/hugs for more details (including other binaries available). I don't have much of a use case for Hugs, so I got the flake to the point where I could start the interpreter and run simple programs. I'm glad to accept pull requests or bug reports. You can find the source and submit any issues at https://github.com/m4dc4p/hugs. Note: I don't have access to Apple silicon, so this build has only been tested under x86. If it works for M1 please let me know, or if you are able to submit a PR I'd welcome it! Enjoy! Justin

2 1

Munich Haskell Meeting, 2022-10-25 @ 19:30
by Leah Neukirchen 23 Oct '22

23 Oct '22

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, October 25 at Cafe Puck 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 can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://nuudel.digitalcourage.de/haskell-munich-oct-2022 Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Re: [Haskell-cafe] Announcing the Haskell Error Index
by Olaf Klinke 21 Oct '22

21 Oct '22

David, the Haskell error index is an awesome idea and the existing entries of high quality. Are there plans to tap the already quite enormous online resources about GHC errors, e.g. this mailing list, reddit and stackoverflow? One can imagine there are numerous brilliant explanations to be found. How did the other languages you mentioned handle the initial populatuion with content? (A general problem knowledge bases suffer: To be useful, a critical mass of knowledge must be accumulated, otherwise users won't be likely to contribute.) Regards, Olaf

2 1

TFPIE 2023 call for submissions (deadline Dec 27th)
by Elena Machkasova 21 Oct '22

21 Oct '22

Please consider submitting and spread the word! TFPIE 2023 Call for papers https://wiki.tfpie.science.ru.nl/TFPIE2023 (January 12th 2023, Boston, MA, USA, co-located with TFP 2023 and POPL 2023) TFPIE 2023 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP and Computational Thinking FP and Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy The pedagogy of teaching FP FP and e-learning: MOOCs, automated assessment etc. Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. In addition, the speaker can provide commentary on effectiveness or student feedback. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 20 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2023 After the workshop, presenters are invited to submit (a revised version of) their article for the formal review. The PC will select the best articles for publication in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Important Dates Submission deadline: December 27th 2022, Anywhere on Earth. Notification: December 30th 2022 (Note: earlier submissions will receive earlier response) TFPIE Registration Deadline: TBA Workshop: January 12th 2023 Submission for formal review: April 19th 2023, Anywhere on Earth. Notification of full article: May 24th 2023 Camera ready: July 1st 2023 Program Committee Christopher Anand - McMaster University, Canada Attila Egri-Nagy - Akita International University, Japan Jason Hemann - Seton Hall University, USA Kevin Kappelmann - Technical University of Munich, Germany Elena Machkasova (Chair) - University of Minnesota Morris, USA Kristina Sojakova - INRIA, France Jørgen Villadsen - Technical University of Denmark, Denmark Registration information See https://wiki.tfpie.science.ru.nl/TFPIE2023 for updated information. Registration and attendance are mandatory for at least one author of every paper that is presented at the workshop. Presenters will have their registration fee waived. Only papers that have been presented at TFPIE may be submitted to the post-reviewing process. Best regards, Elena Machkasova (program committee chair) -- Dr. Elena Machkasova Associate Professor of Computer Science Division of Science and Mathematics University of Minnesota, Morris Office: Sci 2325 (320) 589-6308 http://cda.morris.umn.edu/~elenam/ Pronouns: she/her/hers or any other

1 0

Re: [Haskell-cafe] Announcing the Haskell Error Index
by Douglas McIlroy 21 Oct '22

21 Oct '22

(comment mostly for entertainment) The announcement of the Haskell error index conjured memories of the Fortran I stop book. On an error, the original Fortran compiler executed a halt instruction. To find the cause, one would read the memory address of the halt from the console lights and manually look the address up in the stop book, a thick 11"x17" computer printout. In the Haskell error index, the codes are permanent identifiers for evolving diagnostic explanations. In contrast, Fortran stop numbers varied with compiler version, while the explanations were essentially static. The stop book was indispensable, but far from user-friendly. If reasonably curated, the error index could be a big advance in the latter respect. Doug McIlroy

1 0

Bogotá Functional Programming Interest Group
by Jeffrey Brown 20 Oct '22

20 Oct '22

I imagine people who read Haskell Cafe and live in Colombia might be interested in this new group. It's the closest thing I'm aware of to a Haskell user group in the country. https://www.meetup.com/functional-programming-interest-group-at-puj/ -- Jeff Brown | Jeffrey Benjamin Brown LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown> | Github <https://github.com/jeffreybenjaminbrown> | Twitter <https://twitter.com/carelogic> | Facebook <https://www.facebook.com/mejeff.younotjeff>

2 1