Haskus – A Haskell Framework for Systems Programming | Hacker News Reader

Haskus – A Haskell Framework for Systems Programming

github.com

146 pointsVosporos15 comments

Interesting, I was thinking about something like this, at least for exposing the raw Linux syscalls. I'm really happy this exists. Although I still have no clue what it's useful for, beyond my vague plans to speed up base file I/O and re-implement the RTS in Haskell, which never seemed that important so I never got around to...

I've read https://github.com/haskus/haskus-system/blob/27bc422fccff455... and it still seems pretty weird to store the syscalls at type-level instead of defining them function-by-function. You don't have to define functions one-by-one, just use Template Haskell to generate them... and Syscall.read is much clearer than syscall @"read".

It used to be one function per syscall: https://github.com/haskus/haskus-system/blob/ee3e0a69a263aaf...

I did this to remove the boilerplate code, to make it easier to select the method (foreign primops or safe FFI foreign calls) and to make the conversion from the kernel tables simpler.

However I may have to switch to a Template Haskell solution because the type-level approach with type classes and type families has increased the compilation time and forces me to use `-freduction-depth=0`.

> the type-level approach with type classes and type families has increased the compilation time and forces me to use `-freduction-depth=0`.

Are you on OSX by any chance? I have some similar issues but they don't seem to happen on Linux.

No I develop on Linux.

Invited them here plus sent them these semi-related links in case prior work on systems programming in Haskell helps them:

http://programatica.cs.pdx.edu/House/

http://programatica.cs.pdx.edu/papers.html

Thanks for the invitation. I've read a little bit about House a few years ago, but maybe I should give another look.

My project, however, is more high-level in that I don't plan to write a kernel (device drivers, etc.) as they have done for House.

Ahh. Oh well. I figured it would be fun to look at in worst case. ;)

How world this compare to using inline-C?

tldr: A framework to implement the Linux userspace in Haskell. Different design goals than HalVM.

Not sure from the code on github: If you want to replace the userspace including libc, then what do the RTS parts that need libc do?

Hi, the RTS continues to use the libc as usual. Maybe in some far future we could use a stripped down libc but for now I want to use GHC and Linux unmodified so that the system stays easy to test.

I get hints on GitHub and the website but what is this project exactly? What are you trying to do with it and compared to what?

Obviously I can't speak for the developers, but as it says a full Linux userspace, I will try spell it out - the userspace consists basically of almost anything you can install in Debian. So

* GNU tools (ls, tail, bash, gdb, etc.)

* OS infrastructure (Systemd, Xorg/Wayland, etc.; probably not Mesa/DRM though as he says he doesn't want to do drivers)

* Desktop environments (KDE, GNOME, etc.)

* ... random other packages like Nethack ...

Honestly the goal seems kind of insane, like Don Quixote trying to reach the unreachable star. But I guess it's good advertising for the consulting work, and of course research projects generate useful side benefits. And writing software in Haskell is fun, so they just might succeed :-)

Perhaps as a proof of concept they can do a native implementation of GNU grep in Haskell and publish some timing stats.

It's mostly an experiment into providing an integrated interface leveraging Haskell features (type-safety, STM, etc.) for the whole system: input, display, sound, network, etc. There is still a lot of work to do...

Then in a probably far future I would like to use it to try different (crazy) things. For instance configuring the whole system with type-checked Haskell code (similar to XMonad configuration but for the whole system); provide a better terminal-like interface/protocol replacing stdin/stdout/stderr/term ioctls; generalize Linux sandboxing to all applications (filter syscalls, use namespaces, disk quota, etc.) and manage per-application permissions; etc.

The closest approach is Android which also uses the Linux kernel but doesn't provide a Unix interface to applications.

Makes sense. Esp with the Android example.

Reply on news.ycombinator.com