Keeping Hugs alive

The Hugs Haskell compiler/interpreter is a unique piece of work. Unfortunately, it’s kind of hard to install or build these days. Some time last year I tried to build it and gave up due to C build system arcanea. Is there any interest in bringing it back to life with “modern” CI builds, for example?

It gives me the same “time capsule” vibes that e.g. Common Lisp implementations do. A Haskell that I could target and know that it’s not a moving target. For e.g. teaching or scripting.

The only problem is that there’s no one left to keep it alive. Some distributions have historically provided packages for it, but I’m noticing more often that it’s lagging or not published anymore.

So I’m curious whether there’s any interest from others about keeping it on life support? Also, does anyone maintain a “modernised”/patched version of it privately? I thought about taking the 2006 release or a recent working one from Debian or something, but there might be build system work done on it already.

13 Likes

It gives me the same “time capsule” vibes that e.g. Common Lisp implementations do.

I love that!

Having Hugs crystallized in a Nix derivation sounds quite cool. It would be a fun challenge as well :smiling_imp:

Hugs will always have a special place in my heart. I first learned Haskell doing an RPi project for school. It was GHC 7.something. ghci didn’t work on the RPi, so I used the hugs repl. I learned a lot by using that hugs repl! Forever grateful.

8 Likes

That’s odd - for a version I grabbed from the Hugs site, the "point of stoppage" was that it had been updated to use Cabal during the build process: that failed, so I instead switched to one of the OS-package sources, which I was able to build (I don’t recall having to make any changes - maybe I was just fortunate: no lunar disturbances that day).


2 Likes

I build on Windows using Visual Studio (an out-of-support 2013 version). But yes ran into build system/library complaints around FFI. I’m not trying to build entirely from source (nor calling FFI), so I just ported the FFI objects into the path, and they got linked ok.

Here’s a repo that made a start on trying to modernise/compile from scratch; looks like they just ran out of steam.

…no, “unique” doesn’t quite do it justice: I consider the Hugs interpreter to be an extraordinary piece of work (especially considering the choice of implementation language). Perhaps the only other codebase to even remotely approach its complexity for the given task would be the recently-released Miranda(R) implementation (same choice of implementation language).


>_< …and one crucial reason probably was that I built it on a G/Linux OS (I haven’t had a regular install of “those other OSs” since the late 1990s).


From https://github.com/FranklinChen/hugs98-plus-Sep2006/tree/master/README.md :

…let’s ask @FranklinChen (if that’s his repository :-)

I like your thinking: having it maintained would be good indeed; though on Linux I think things not that bad:

https://repology.org/project/hugs98/versions

4 Likes

Perhaps I’ve missed something (I’m just passing by from the newsletter summary), but just trying out nix shell nixpkgs#hugs -c hugs gets me a running Hugs shell. (nix run nixpkgs#hugs is broken due to an irrelevant naming error.)

Looking at the derivation, it seems to be based on the Arch PKGBUILD recipe, using one patch file from Arch and a handful of configure flags but nothing really surprising. I would hazard a guess that with a basic build-essentials and bison, you should be able to get it running with the classic gunzip, ./configure, make, make install incantation if you use the same configure flags.

5 Likes

I stopped trying to maintain my minimally patched original version of Hugs. I think there are others out there who have done more extensive modifications.

2 Likes

…this being a small sample:

1 Like

This does seem to be basically what I was thinking (I didn’t even consider it would be there!)

Give Hugs its own native-code generator so it can be used to build stand-alone whole-program binaries? It’s predecessor - Gofer - included gofcc, which compiled via C…

It is packaged in nixpkgs, though I have not tried it out.

Do you mean whole-program executables? Or modules (libraries) that can be linked together? If the latter, I think there’ll be difficulties with separate compilation of overlapping instances. Hugs wants to see all the instance decls (and know they are all) to do instance resolution.

Whole programs (now updated previous post) - Hugs already deals with individual modules reasonably well, so I don’t really see a need to individually compile binaries for those (and hence escaping the requirement for some lumbering version-tracking bureaucracy for binary artifacts). Moreover, since Hugs would already have the entire program in memory, it could use whole-program optimisations more easily than other implementations.

So no library binaries - only compile whole programs.