[Nix-dev] Use Haskell for Shell Scripting
Ertugrul Söylemez
ertesx at gmx.de
Tue Feb 10 16:05:13 CET 2015
> I think you are thinking too big-system-design instead of
> quick-scripting about that.
Let's say I don't draw a line between small systems and large systems
when it comes to abstractions, because algebraic abstractions are cheap.
IMO a minimum requirement for a language to be called "functional" is
that functions are cheap. I mean cheap as in "almost free", just like
mutable variables are almost free in imperative programming.
Quantification ("generics" in most languages) must be entirely free.
It's not in C++, but in boxing languages it is.
Now if quantification is free and your functions are almost free, then
algebraic abstractions are also almost free. You might as well use them
everywhere, even in your quick-n-dirty scripts, because they make your
code shorter, more maintainable and usually more readable as well
(especially the types).
While you're reading this you should not think of OOP. OO abstractions
are expensive in every way. They make your program slower and your
source code longer. They are not suitable for quick-n-dirty scripts.
> I have added an external module to StumpWM that goes completely
> against the default logic of connecting screens, workspaces and
> windows.
>
> It just moves windows between the workspaces when it needs to.
>
> I still use the hard parts of a WM (X protocol handling) and just
> added my own implementation of the fun parts.
Yeah, that sounds pretty much like what I do right now, except with a
different WM at the core.
> I think I was not clear with my idea about Ratpoison. I meant the Unix
> way of doing things: there is Ratpoison that can easily receive
> commands to change the splits and move the windows. Your logic is in
> Haskell and it just sends commands to Ratpoison (which has been
> debugged once).
The Unix philosophy can manifest in a number of ways. Usually you make
programs pipe-friendly and perhaps add a configuration file. That's the
traditional approach, which has one huge drawback: When communicating
all structure must be flattened, because pipes understand only the
"stream of bytes" notion. Then at the receiving end the structure must
be recovered from the byte-stream. For long-running programs like a WM
it also means that you need to act non-blockingly and handle errors
sensibly.
An interesting alternative is that you don't make your program a
"program" in the first place. After all what is a "program"? It's a
library together with a `main` procedure. Just leave out `main`. Now
it's just a library and "configuring" amounts to the user writing an
actual program that uses the library. That way there is no need to go
through the flatten-and-recover process from above. You can stay within
the language's type system. That's what most Haskell programs do,
including xmonad.
So I'm probably already doing what you're suggesting, except that it
doesn't look like Unix, because there is no "pipe" involved. =)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150210/6618389a/attachment.bin
More information about the nix-dev
mailing list