- Haskell-Cafe - Haskell.org

Haskell survey 2022
by Henning Thielemann 03 Nov '22

03 Nov '22

It seems there is a survey on Haskell Weekly but I have not seen an announcement on the mailing lists: https://haskellweekly.news/survey/2022.html

1 0

[ANN] mtl-2.3.1
by Emily Pillmore 31 Oct '22

31 Oct '22

Hello Ghosts and Ghouls, After a period of spooky deliberation and well-received release candidate, Koz and I are pleased to announce `mtl-2.3.1`, which features the following hellish changelog: * Add `modifyError` to `Control.Monad.Error.Class`, and re-export from `Control.Monad.Except`. * Make the `MonadCont` instance for `ContT` more polykinded; now, `r` is allowed to be of an arbitrary kind `k`, rather than only `Type`. * Add a generic `liftCallCC` for use with any `MonadTrans`. * Add `modifyError` to `Control.Monad.Error.Class` * Return re-export of `ExceptT` and related functions to `Control.Monad.Except`. * Add `label` function to `MonadCont` If you wish to migrate to `mtl-2.3.x` and have not yet done so, please refer the migration guide in the repo: https://github.com/haskell/mtl/blob/master/docs/Mtl-2.3.x-Migration.md A release has been published on the github repository under the tag v2.3.1. Happy Halloween! Emily + Koz

1 0

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 31 Oct '22

31 Oct '22

Dear all, If you or one of your students recently completed a PhD (or Habilitation) in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, 200+ published to date, deadline 30th November 2022. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th November 2022 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the student and the advisor/supervisor although we encourage them to coordinate. Habilitation dissertations are also eligible for inclusion. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 30th November 2022. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ 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

Apply now for maintainership for the `cassava` package
by Andreas Abel 31 Oct '22

31 Oct '22

Looking for maintainer(s) for `cassava`. Please see https://github.com/haskell-hvr/cassava/issues/218 if you are interested in this package. (And answer there.) -- 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

Package takeover request: webdriver
by Tom McLaughlin 31 Oct '22

31 Oct '22

This package is here: http://hackage.haskell.org/package/webdriver. I opened an issue a few weeks ago asking if a new maintainer was wanted: https://github.com/kallisti-dev/hs-webdriver/issues/188 I've opened various PRs (as has the rest of the community) but there hasn't been a commit by the author since June 2019. Thanks! Tom

3 3

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