Keeping Hugs alive

[chrisdone]

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.

[Ambrose]

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

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.

[atravers]

@chrisdone

Some time last year I tried to build it and gave up due to C build system arcanea.

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).

---

@Ambrose

Having Hugs crystallized in a Nix derivation sounds quite cool.

[ANN] - Hugs for MacOS (x86) - via Nix Flakes

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…

[AntC2]

@atravers

I don’t recall having to make any changes

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.

[atravers]

@chrisdone

The Hugs Haskell compiler/interpreter is a unique piece of work.

…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).

---

@atravers

I don’t recall having to make any changes […]

>_< …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).

---

@AntC2

https://github.com/FranklinChen/hugs98-plus-Sep2006/tree/master/src

[it] looks like they just ran out of steam.

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

I have updated the source code of the original 2006 distribution to make it build again today, on Mac OS X in particular.

I am maintaining this repo of Hugs for historical purposes.

I have not tested other platforms but would welcome verification or additional portability fixes).

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

[juhp]

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

[zarybnicky]

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.

[FranklinChen]

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.

[atravers]

…this being a small sample:

• Hugs.js

• Closure to Home: Hugs for the Nintendo DS

• GitHub - trenttobler/android-termux-hugs: Adaption of https://github.com/conscell/hugs-android (hugs haskell interpreter) so it can be built and run using the android termux app.

• FatHugs

[Ambrose]

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

[atravers]

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…

[MangoIV]

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

[AntC2]

@atravers

so it can be used to build stand-alone (executable) binaries?

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.

[atravers]

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.