[Nix-dev] Use Haskell for Shell Scripting

[Michael Raskin]

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

Data type declarations are not free in any case, I think.  

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

Well, you started talking like you were considering some limitation of 
XMonad hard to work around.

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

Well, with sockets it is easier to do decoupling, and cross-language
development.