- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] (Online) Utrecht Summer School on Advanced functional programming
by Olaf Klinke 07 May '21

07 May '21

> The lectures will cover several more advanced topics regarding > programming with types in Haskell, including topics such as: > > * monads and applicative functors; > * lambda calculus; > * generalized algebraic datatypes; > * datatype generic programming > * type families and type-level programming; Even if the schedule is yet to be finalized, a definitive list of topics covered would be nice. Thanks, Olaf

1 0

wai-middleware-validation
by Kenzo Yotsuya 07 May '21

07 May '21

Dear Haskell-Cafe, I've uploaded a new package named wai-middleware-validation to Hackage. This is a WAI middleware to automate the validation of request and response bodies according to the schema defined in OpenAPI. I hope Web API developers using OpenAPI will give it a try. https://hackage.haskell.org/package/wai-middleware-validation https://iij-ii.github.io/wai-middleware-validation/ Thanks, Kenzo Yotsuya

1 0

Repeating type variables in MultiParamTypeClasses instance heads
by Leif-Erik Krüger 07 May '21

07 May '21

Hello Haskell-Cafe, I have a question regarding the rules on type class instances with the MultiParamTypeClasses extension. For single-parameter type classes, there is the restriction that an instance head must have the form `C (T a1 ... an)`, where `C` is a type class, `T` is a data type constructor and `a1 ... an` are distinct type variables ( https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/instances.html ). To my knowledge, this restriction ensures the impossibility of potential overlap between instances (except for the case where two instance heads are equivalent, but this case is caught by an error message). This restriction can be lifted with the FlexibleInstances extension, so that instances like `instance C (a, a, b)` and `instance C (a, b, b)` are allowed. As can be seen in this example, FlexibleInstances introduces the potential of overlap with single-parameter type classes. When using MultiParamTypeClasses without FlexibleInstances, the current restrictions on instance heads are similiar to those for single-parameter classes. For each parameter, the instance type must have the form `(T a1 ... an)` with `a1 ... an` being distinct from one another, but type variables can be shared between instance types. Therefore, instances like `instance D [a] [a] [b]` and `instance D [a] [b] [b]` are allowed and do cause potential overlap. If there was the restriction of all type variables in the instance head being different from one another however, I think there would be no potential for overlap, just like with single-parameter type classes. To me, these instances allowed by MultiParamTypeClasses seem similar to the single-parameter class instances that are only possible with FlexibleInstances. And just like FlexibleInstances for single-parameter class instances, they introduce potential overlap, so that the MultiParamTypeClasses extension by itself becomes less "safe" than it otherwise would be. Therefore, it seems reasonable to me to only allow these repeated type variables in instance heads with the FlexibleInstances extension. So, is there a good reason for the design choice of allowing these kinds of overlap without FlexibleInstances? Am I missing something here? Or are the current rules the way they are because of historic reasons? Best regards, Leif-Erik Krüger

4 3

bootstrapping a monad via continuations
by Olaf Klinke 06 May '21

06 May '21

Dear Café, I've been scratching my head over a monad instance. I wonder whether there is a deeper theory behind this. Suppose you have a functor T and you happen to find a special type r such that there is a natural embedding into the continuation monad Cont r. More precisely, if there are natural transformations trans :: forall x. T x -> Cont r x trans' :: forall x. Cont r x -> T x with trans' . trans = id and trans . trans' . return = return trans . trans' . (=<<) (trans . f) = (=<<) (trans . f) then you can define monad operations for T so that trans becomes a monad morphism. Once that T is a monad, one can invoke a theorem from a 1970 paper by Anders Kock and obtain Eilenberg-Moore T-algebra structure on r, and the entire monad structure of T can be recovered from this single T-algebra. Examples of this scheme in the mathematical literature are the Riesz representation theorem, which identifies measures on X with a subset of the space of real functionals (X -> R) -> R. Ultimately, the monad structure of the functor of measures is encoded in the operation that sends a measure on R to its mean. Anders Kock's theorem says: (1) There is a bijecitive correspondence between natural transformations T -> Cont r and functions T r -> r. (2) In particular if T is a monad, (1) restricts to a bijection between monad morphisms and Eilenberg-Moore algebra structures. (Incidentally, this is what underlies the continuation monad transformer: Apply to the structure join :: m (m r) -> m r.) It thus seems that my observation is a kind of converse to part (2), namely if a function T r -> r is an Eilenberg-Moore algebra structure, then T is a monad. The preceding sentence is self-referential though, because the property of being an Eilenberg-Moore algebra depends on monad structure already present. As usual I suspect the answer in one of Edward Kmett's packages, but my Category-Fu is not strong enough to identify the matching concept. Olaf

1 0

Safe Haskell?
by Richard Eisenberg 04 May '21

04 May '21

Hi café, Do you use Safe Haskell? Do you know someone who does? If you do, which of Safe Haskell's guarantees do you rely on? Here, a user of Safe Haskell is someone who relies on any guarantees that Safe Haskell provides, not someone who makes sure to have the right pragmas, etc., in your library so that users can import it Safely. Context: Safe Haskell is not lightweight to support within GHC and the ecosystem. Despite being a formidable research project with a (in my opinion) quite worthwhile goal, it's unclear which of Safe Haskell's purported guarantees are actually guaranteed by GHC. (The lack of unsafeCoerce is not actually guaranteed: https://gitlab.haskell.org/ghc/ghc/-/issues/9562 <https://gitlab.haskell.org/ghc/ghc/-/issues/9562>.) Recent design questions about what should be Safe and what shouldn't be (somehow cannot find the discussion after a few minutes of searching; perhaps fill this in) have been answered only by stabs in the dark. The status quo is causing pain: https://gitlab.haskell.org/ghc/ghc/-/issues/19590 <https://gitlab.haskell.org/ghc/ghc/-/issues/19590>. There are hundreds (maybe thousands) of lines of delicate logic within GHC to support Safe Haskell. These parts of GHC have to be read, understood, and maintained by people with limited time. I thus wonder about deprecating and eventually removing Safe Haskell. I don't have a concrete plan for how to do this yet, but I'm confident we could come up with a migration strategy. The set of people who would win by removing Safe Haskell is easy enough to discover. But this email is intended to discover who would be harmed by doing so. If you know, speak up. Otherwise, I expect I will write up a GHC proposal to remove the feature. Thanks, Richard

18 41

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 04 May '21

04 May '21

Dear all, If you or one of your students recently completed a PhD 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 31st May 2021. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st May 2021 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 PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 31st May 2021: o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD 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

Promoted data types
by coot＠coot.me 03 May '21

03 May '21

Hello, Currently with `DataKind` extension, Haskell allows to promote terms / types to types / kinds. Currently, one cannot write: ``` data K a where K0 :: forall (x :: a). x -> K a ``` Because `K0` is both a term and a type constructor, and as a term and one cannot represent `x` of kind `a`. Is there a proposal or an issue to allow such declaration and error at use sites of `K0` as a term, rather than at declaration site? Best regards, Marcin Szamotulski

4 9

[Announcement] ZuriHac 2021 (18-20 June) - Registration now open
by Jasper Van der Jeugt 02 May '21

02 May '21

Hey Haskell friends, We are happy to announce that you can now register for ZuriHac 2021. It will take place from Friday 18th to Sunday 20th of June. Like last year, we are holding the event online. While we are sad that we don't yet get to see each other in person, this also allowed ~1000 people to join in 2021, instead of the usual 400-500 in Zurich. We have a couple of exciting things lined up for you this year. Here is a peek preview, but you can always check out https://zurihac.com for up-to-date information. This year, we are honoured to have talks by: - Emily Pillmore - Gabriele Keller - John Hughes - Veronika Romashkina And we have a couple of tutorials and teaching tracks in the works, as well as one more talk. We put a special focus on covering the whole beginner, intermediate, advanced spectrum: - There will be an advanced track held by our friends at Well-Typed. - digitally induced will teach you IHP, a new batteries-included web framework that has been gaining a lot of traction. Check it out at https://ihp.digitallyinduced.com/. - There will be a workshop on Unison, an exciting programming language that shares a lot of Haskell's syntax and semantics. Have a look at https://unisonweb.org/. We are working on more talks and tutorials, so expect further details to be communicated in the coming weeks. Keep an eye on our website! Apart from this, there will be the usual stuff that makes ZuriHac so much fun. There will be projects to hack on with other people, and the possibility to bring your own. There will be plenty of socialising, some impromptu hallway tracks, friendly fellow Haskellers to help you out, and an overall welcoming vibe. A quick note on how the online event works: - The main hub for the event will be on our Discord server. It worked really well for us last year, since it provided a sense of togetherness. It's easy to use, and it has chats, voice, and video. You will get a link when you register. - The talks will be streamed (and recorded) on YouTube. Q&A will be held on Discord. Check out last year's excellent talks: https://youtube.com/playlist?list=PLiU7KJ5_df6aZbNfh_TUJt-6w9N3rYkTX Registration is free and open as of right now: https://zureg.zfoh.ch/register/ Looking forward to seeing you in June! The Zurich Friends of Haskell - https://zfoh.ch

1 0

Free online intro/advanced Haskell courses [YouTube]
by Graham Hutton 01 May '21

01 May '21

Hi all, For the last few months, I've been preparing YouTube videos for the introductory and advanced Haskell courses that I teach to students at the University of Nottingham. The courses have now finished, and the full sets of videos are now available: Intro course: http://www.tinyurl.com/haskell-notts Advanced course: http://www.tinyurl.com/haskell-notts2 There’s also a 25% discount for the textbook on which both of the courses are based, Programming in Haskell: Discount link: http://tinyurl.com/25pct-off Best wishes, Graham — 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.

3 2

ANN: second release candidate for stack-2.7
by Emanuel Borsboom 30 Apr '21

30 Apr '21

You can download binaries for this pre-release from https://github.com/commercialhaskell/stack/releases/tag/rc%2Fv2.7.0.3 Please test it and let us know if you run into any trouble. If all goes well, we expect to release the final version in X weeks. Release notes: * Stack's bindists are now built with GHC 8.10.4, and our `stack.yaml` has moved to lts-17.10. This means Stack can now be built on macOS 11.0 (Big Sur) without ugly workarounds. GHC 8.8 is now the minimum GHC version supported for building Stack itself (but this does not effect _users_ of Stack, which still supports using much older GHC versions). **Changes since v2.7.0.1:** (no changes)

1 0