
Haskus – A Haskell Framework for Systems Programming - Vosporos
https://github.com/haskus/haskus-system
======
Mathnerd314
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...](https://github.com/haskus/haskus-
system/blob/27bc422fccff4550af0a7f4bb9458a484b163d2c/src/lib/Haskus/Arch/X86_64/Linux/Syscall.hs#L72-L80)
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".

~~~
hsyl20
It used to be one function per syscall: [https://github.com/haskus/haskus-
system/blob/ee3e0a69a263aaf...](https://github.com/haskus/haskus-
system/blob/ee3e0a69a263aaf74554e6a18098812d8fc0d415/src/lib/ViperVM/Arch/X86_64/Linux/Syscalls.hs)

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

~~~
codygman
> 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.

~~~
hsyl20
No I develop on Linux.

------
nickpsecurity
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/House/)

[http://programatica.cs.pdx.edu/papers.html](http://programatica.cs.pdx.edu/papers.html)

~~~
hsyl20
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.

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

------
georgewsinger
How world this compare to using inline-C?

------
throwaway161220
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?

~~~
hsyl20
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.

~~~
nickpsecurity
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?

~~~
hsyl20
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.

~~~
nickpsecurity
Makes sense. Esp with the Android example.

