end of an era, #Hugs98 #HaskellHugs #Haskell has been removed from #Debian

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121581

Hugs98 is a Haskell interpreter implemented in C, historically important, with different (maybe better) error messages to GHC. Sadly most of the Haskell library ecosystem is GHC-only.

Some forks of upstream (last release 2006) are still active:

https://github.com/cjacker/Hugs 2019 improvements based on original darcs repo with full history; lots of bundled packages and a more recent base package version

https://github.com/claudeha/Hugs my 2024 fork of cjacker's improvements with some bugfixes and a branch with OverloadedStrings support

https://github.com/augustss/hugs98-plus-Sep2006
updated 2025 based on 2006 tarball (no history), primarily exists to bootstrap MicroHs

https://github.com/augustss/Hugs probably ignore this one, 2006 tarball again

probably more that I have missed

my microbenchmark compiled with ghc-9.4.8 -O2 is 3.18 times faster when using Int than Int64, even though both are signed 64bit integer types on my platform.

similarly, runhugs is 1.63 times faster when using Int than Int32.

#Haskell #GHC #Hugs98 #optimisation

```
import System.Time (ClockTime(..), getClockTime)

main :: IO ()
main = do
TOD start_s _ <- getClockTime
let loop :: Int -> Int -> IO ()
loop sum i = do
TOD now_s _ <- getClockTime
if now_s - start_s < 20
then do
let sum' = sum + lcm 666 i
i' = i + 1
sum' `seq` i' `seq` loop sum' i'
else do
print i
print sum
loop 0 1
```

500 lines of #C to implement the #TidalCycles pattern

```
rev (_fast 3 (cat [0,1,2,3]))
```

Eventually hoping to port my #Hugs98 -based Tidal-like eDSL to #CPlusPlus transpiler experiments to target C in the hope that compilation times are better - in this short test there is already an almost 10x improvement which is promising - 0.3 seconds (C) is bearable latency for #LiveCoding , 2.7 seconds (C++) is pushing it (timings on desktop).

Need to see what to do about ControlPattern / ValueMap. Fiddled a bit with Hugs.Trex extensible records / row types but it wasn't useable for this.

Did some other #Haskell experiments storing field types in ControlPattern along side the Pattern ValueMap, and ensuring types are compatible when combining (i.e. all fields with the same name must have the same type) / outputing (i.e. "s" must be present and be a String, optional fields must have sensible types).

I think when converting to C I could do something like a big record of maybes (struct of tagged unions), as the above shenanigans means I know the universe of possible fields. But then I might as well do the full Dirt-OSC list of fields (think there are 30 or so), for simplicity (no need to generate many variants of code for different field-sets)...