Huh, so it's not giving you full Haskell, but restricted to an API of under 300 functions: https://chrisdone.github.io/hell/api/ Interesting. I guess that's what made this bit possible:
It was easy at the start of this project in early 2024 to say I
like reading the code, because I was the only user. Now, after
reading the code of a few colleagues, I still find it very easy
to read the code.
ie. you don't have to start hoogling library functions to read a new script (while having more sane behaviour than bash).
My main issue with Yet Another Scripting Language is that you have to install it to new systems and you'll find some dependency issue with idunno glibc being the wrong version or arm vs intel etc. (Case in point: https://github.com/chrisdone/hell/releases only has
hell-linux-x86-64bit ) I wonder, could you use this with https://github.com/augustss/MicroHs ? They seem like a good combination, MicroHs being extremely portable, Hell having a restricted API and presumably quite stable dependencies.
The intention -- ideally -- is to distribute statically linked binaries. So the one you mentioned is statically linked with musl, so it doesn't depend even on libc, it just needs the Linux ABI. My vision is that once you've got a hell binary, like bash, it'll work for years and years on a system. I'd like to start building arm64 builds, too, but just haven't started yet.
For MicroHs, you might be able to build a different kind of Haskell using a separate codebase. One selling point for having an interpreter written with GHC Haskell is that Hell piggybacks on the GHC runtime and libraries. So it has concurrency, handles, exceptions, process launching, etc. that behave in the usual way, as it's literally calling those same standard functions. That's not discounting the idea that someone could use micro-hs, of course. That'd probably be quite viable.
Readit News
My main issue with Yet Another Scripting Language is that you have to install it to new systems and you'll find some dependency issue with idunno glibc being the wrong version or arm vs intel etc. (Case in point: https://github.com/chrisdone/hell/releases only has hell-linux-x86-64bit ) I wonder, could you use this with https://github.com/augustss/MicroHs ? They seem like a good combination, MicroHs being extremely portable, Hell having a restricted API and presumably quite stable dependencies.
-----
(btw footnote 3 is footnote 1 again)
For MicroHs, you might be able to build a different kind of Haskell using a separate codebase. One selling point for having an interpreter written with GHC Haskell is that Hell piggybacks on the GHC runtime and libraries. So it has concurrency, handles, exceptions, process launching, etc. that behave in the usual way, as it's literally calling those same standard functions. That's not discounting the idea that someone could use micro-hs, of course. That'd probably be quite viable.