The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org. GHC 9.8 will bring a number of new features and improvements, including:...
And a completely crazy talk by Ben Lynn about building a Haskell compiler based on an old concept from logic research. Just incredible fun to watch: https://www.youtube.com/watch?v=3kMvXXGXaws
@joeyh heartwarming to see experiments like this :) i wouldn't say time is wasted, though much of the glue code will indeed become obsolete once i really get an mvp of jsffi working
Today I spent a few hours trying to track down a problem deep in a helper module of a complex production application written in #Haskell. Among other things, it involves threads, a monad transformer stack (3 or 4 levels deep, I think?), an SQL database, and HTTP calls to an external service.
In the end, I managed to boil one issue in the code down to the following crucial lines:
forever_mpl :: Monad m => m a -> m b<br></br>forever_mpl m = fix (m >>)<br></br><br></br>forever_mpf :: Monad m => m a -> m b<br></br>forever_mpf m = fix (self -> m >> self)<br></br>
In theory, both of these should be equivalent to forever from the base library. However ...
In one place in the code, using forever_mpl (the first definition) works correctly: It repeats an action forever. But switching to forever_mpf (the second definition) makes the code hang instead (at 0% CPU). Why?!
I know the answer now, so here's a #debugging challenge: Can you think of a reason why these two definitions should behave differently? Can you implement a Monad instance with a >> that distinguishes between them somehow?
@barubary It could be bottom depending on the monad instance, but I get your point. Anyway here is my solution to the puzzle:
-- T.hs
{-# LANGUAGE Strict #-}
{-# OPTIONS_GHC -O0 #-}
module T where
import Control.Monad
import Data.Function
forever_mpl :: Monad m => m a -> m a
forever_mpl m = fix (m >>)
forever_mpf :: Monad m => m a -> m a
forever_mpf m = fix (\self -> m >> self)
-- Main.hs
import T
import Control.Monad
data Id a = Id a deriving Functor
instance Applicative Id where
pure x = Id x
(<*>) = ap
instance Monad Id where
Id x >>= k = Id (case k x of (Id y) -> y)
main1 = case forever_mpl (Id ()) of Id{} -> putStrLn "Done"
main2 = case forever_mpf (Id ()) of Id{} -> putStrLn "Done"
The latest and greatest GHC version (9.8.2) is now available in the Alpine Linux Edge repositories and will be included in the upcoming 3.20 stable release.
Someone who knows #Haskell and ML: is there a writeup somewhere explaining how first-class modules (a la ML) can do similar things to Haskell type classes? I'm finding it hard to figure that out.
To give a more concrete case: suppose I wanted to write something like Control.Applicative, which provides an 'interface' Applicative with some methods, as well as functions that work for any Applicative. How would I do this with ML-style first-class modules?
@koz I would like to see such a comparison post too. In the meantime I found this stackoverflow question which contains a way to do it using an ML functor: https://stackoverflow.com/questions/48989663/monads-and-sml-modules. The obvious downside is that you have to explicitly state which monad to use at some point.
Another lesser known difference is that I believe you can't instantiate an ML signature with a polymorphic type. For example you can't write an instance of that MAPPABLE signature for a type like Map k v. At least not such that it is still polymorphic over the key type k.
@koz Not quite your case, but “The next 500 module systems” paper gives a nice overview of the problem, bridging modules, type classes and records (and scopes!).
The term 'telemetry' can raise a lot of concerns, especially within the realm of #OSS. In the latest episode of #TheHaskellInterlude, Joachim Breitner and Andres Löh interview @avi_press, the CEO of @scarf_oss. Learn more about the episode here: https://haskell.foundation/podcast/47/ #Haskell
I recently came across https://simplex.chat. I really liked it just by reading how it works. But I took a look at the source code today, and I was like: “Oh coool it's in #haskell. Oh, daaaamn they're using #nix quite heavily. I love it. 😍 “
The #Haskell#Unfolder is now 1 year old! In the anniversary episode, Edsko and I will return to the very first topic and consider (un)folds, but now in a more generic setting. Live on YouTube 2024-05-01 at 1830 UTC.
New blog post by my colleague Finley on "Choreographing a dance with the GHC specializer (Part 1)". This is in addition to our #Haskell#Unfolder episode on the same topic tomorrow, 2024-04-16, at 1830 UTC on YouTube.
@someodd, here's a few thoughts on #haskell packaging/distribution:
Support the widest range of GHC versions, deps, and all related tools you can reasonably manage, reducing unnecessary friction.
Get your packages and their dependencies into Stackage nightly and keep them there. From there they will trickle into Stackage LTS, which is a starting point for many packaging systems.
