Re: [Nix-dev] Use Haskell for Shell Scripting
Remember that we're talking about very different paradigms. I can totally see how you would want and love macros in CL. In CL you encode your solution in such a way that using macros is the natural thing to do, and then lexical manipulation is probably something that comes in handy. In Haskell your encoding is entirely different, so you wouldn't use macros in the first place. Instead you would use non-strict higher-order functions together with type classes. And of course Common Lisp does have higher-order functions; do type classes add any encoding power? I always thought they were needed to keep track of all that happens, and working duck typing with optional multiple dispatch allows to write the same code but with less safety. Type classes are essentially just principled overloading. They allow you to write reusable code bound to certain *features* (rather than specific types): multiCoreMapReduce :: (Monoid b) = (a - b) - [a] - b multiCoreMapReduce f = fold . parMap rseq f Whenever `b` is a monoid, the above function is a multi-core MapReduce implementation. Here `Monoid` is a class. There is a myth on the Lisp side that Common Lisp has a paradigm that means it wouldn't benefit from some more static annotation and analysis features; there is a myth in many non-Lisp places that feature X makes macros unneeded. Both are myths. Just a trivial with-fields (in its many many forms) is an example of a thing that is trivial with macros, useful enough to be built into Object Pascal and doesn't perform its primary task (reducing clutter) if implemented without macros. I couldn't find any information online about what `with-fields` is, but From its name I'm just going to assume that it brings stuff into scope semi-automatically, i.e. it does something a regular function cannot do. Does a CL programmer benefit from this? Absolutely! Would programmers of most languages benefit from this, for example Object Pascal? Likely! Would a Haskell programmer benefit from this? Well, probably not as much as you would want them to. Let's turn the table: Laziness is a very powerful feature in Haskell. Could I convince you of that? Probably not, because you're not a Haskell programmer and you wouldn't find it very useful in CL. But I may be crazy about laziness and think: How can anyone deny the usefulness of laziness?. You're suffering from the same fallacy w.r.t. macros. Let me explain. There is a *very common* myth on the CL side that macros are so powerful and so useful in CL that they must be powerful and useful *everywhere*. That may easily lead you into the trap of thinking that any language that lacks macros has a serious drawback compared to CL. But that's a myth. I'll assume that right now you're thinking: Oh, come on, macros allow you to manipulate lexical features, scope, introduce new views to data, build functions automatically, etc. How can they be useless in any language?. I could fall into the same trap: Oh, come on, laziness allows you to build virtual data structures, specify if, how and when to evaluate (e.g. in parallel), apply semantically huge/infinite transforms in O(1), use action DSLs, etc. How can it be useless in any language?. Yet it would still be pretty useless in CL. Let me go one step further: Macros would do more harm than good in Haskell, if people would actually be going to use them. In fact we do have a similarly powerful macro system called TH. We even have a system for custom syntax called QuasiQuotes, if you need it. Our TH and QQ are even type-safe! Yet most experienced Haskell programmers try to avoid both of them as much as possible, and for a good reason, which is beyond the scope of this mail. Now macros-considered-harmful probably goes even worse against your world-view than macros-considered-useless. But consider this: In a similar way laziness would not only be pretty useless in CL, it would do more harm than good, because it entails the kind of non-determinism that requires all side effects to be expressed in terms of a lazy domain-specific action language (which is our `IO`). You probably don't want that. Combined with macros it would have the potential to render CL unpredictable. Modern van Laarhoven lenses are a powerful abstraction for accessing data structures, mainly because a lens does not necessarily correspond to a certain concrete field (it can correspond to many fields or to a logical alternate view of certain data) and also because both lenses and lens operators are first class values. _Which_ lenses should be used, actually? It looks like there is a controversy about which packages are the correct ones to use and which should be considered just a proof-of-concept playground for new ideas. It doesn't actually matter. One nice thing about van Laarhoven lenses is that all the lens packages are compatible with each other. Most people use the `lens` library though, because it is very
Re: [Nix-dev] Use Haskell for Shell Scripting
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. =) signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Data type declarations are not free in any case, I think. Compared to what? Algebraic abstractions usually compile to exactly the code you would have written if you had not used abstraction. Well, you started talking like you were considering some limitation of XMonad hard to work around. I am. I'm using a tree-shaped set of workspaces, but I need to encode this tree within the names of the workspaces, which is incredibly awkward. 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. Decoupling seems unrelated, but the cross-language point is valid of course. Also sockets can work over a network. So yeah, it's a tradeoff. For my window manager I really don't want to go through that complexity. It's written in Haskell, I'd like to configure in Haskell and I'm not planning to offload my WM state to another machine. So I'm glad I can just use xmonad as a library. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Data type declarations are not free in any case, I think. Compared to what? Algebraic abstractions usually compile to exactly the code you would have written if you had not used abstraction. Data type declarations have to be written. Store-everything-in-hash- tables is slower but quicker to write as long as I can keep the entire program structure in my head. Also I am trying to learn to write reasonable Haskell code for a small data-crunching script without just writing Fortran into Haskell; well, many of its features are minor annoyances in that mode even if they are useful for giving structure to a large program. It's seldom that you have to write your own data types, if you don't want to. Basic types, functions, products and coproducts can express anything you want that isn't a tightly packed array of machine words. But if you really want to dump everything into a table-like data structure, you can use Data.Map or Data.IntMap for everything. Together with GHC's OverloadedLists extension this should make your code just as short as the usual everything-is-a-hash-table in most scripting languages. However, you may want to write type signatures anyway. It doesn't increase your development time considerably. Well, you started talking like you were considering some limitation of XMonad hard to work around. I am. I'm using a tree-shaped set of workspaces, but I need to encode this tree within the names of the workspaces, which is incredibly awkward. Well, I think you should be able just to write alternative UI for workspace selection simply ignoring the old one, no? Unfortunately not. Everything in xmonad goes through the core data structure StackSet. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
It's seldom that you have to write your own data types, if you don't want to. Basic types, functions, products and coproducts can express anything you want that isn't a tightly packed array of machine words. But if you really want to dump everything into a table-like data structure, you can use Data.Map or Data.IntMap for everything. Together with GHC's OverloadedLists extension this should make your code just as short as the usual everything-is-a-hash-table in most scripting languages. Actually, I use a ton of tuples-as-records in my crunching code in Common Lisp or Julia. Some of the shell tricks based on expansions are portable to Lisp, not worth it in Julia and definitely too costly in Haskell (learning Template Haskell is definitely outside my plans). I don't really know TH either. Occasionally I use TH actions defined in a library (for example to derive safecopy instances or, less commonly, to auto-generate lenses). But TH somehow feels wrong and ugly. However, you may want to write type signatures anyway. It doesn't increase your development time considerably. I also need to write matching to extract data from deep structures, no? I'm not sure what you mean by that. Perhaps you can drop me an off-list mail, so we can talk about your specific application. I'm using a tree-shaped set of workspaces, but I need to encode this tree within the names of the workspaces, which is incredibly awkward. Well, I think you should be able just to write alternative UI for workspace selection simply ignoring the old one, no? Unfortunately not. Everything in xmonad goes through the core data structure StackSet. Why is it a problem? For hierarchically structured workspaces you just tell XMonad core to select the low-level workspace. The trouble is that xmonad's idea of set of workspaces is encoded as a list zipper. It does not allow me to encode the tree. It only ever holds *lists* of workspaces and does not abstract over this data structure. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Some of the shell tricks based on expansions are portable to Lisp, not worth it in Julia and definitely too costly in Haskell (learning Template Haskell is definitely outside my plans). I don't really know TH either. Occasionally I use TH actions defined in a library (for example to derive safecopy instances or, less commonly, to auto-generate lenses). But TH somehow feels wrong and ugly. In both Julia and Common Lisp I use macros for many tasks and they make life much more comfortable. Of course, Haskell type system may make it hasrder to use macros. Oh, Common Lisp (CL) macros don't correspond to TH, but rather to regular functions in Haskell. We have first class actions together with lazy evaluation. What is code is data is code in CL is actions are first class values in Haskell. You only need TH when you need to generate something that is not first class, for example class instances. However, you may want to write type signatures anyway. It doesn't increase your development time considerably. I also need to write matching to extract data from deep structures, no? I'm not sure what you mean by that. Perhaps you can drop me an off-list mail, so we can talk about your specific application. Well, it looks like field names are not scoped and if I use plain ADT I have to write pattern matching to extract data from a member of a member of a structure. You can chain both functions and lenses. Extraction via functions: (innerField . outerField) value Extraction via lenses: value ^. outerField . innerField Update via lenses: (outerField . innerField .~ 15) value You can even get completely imperative by using a state monad: outerField . innerField .= 15 outerField . otherInnerField .= blah The trouble is that xmonad's idea of set of workspaces is encoded as a list zipper. It does not allow me to encode the tree. It only ever holds *lists* of workspaces and does not abstract over this data structure. So? Keep your own structure and keep pointers to XMonad-stored entries. Yes, I do that, arguably not in the most elegant way possible, because the predefined workspace switchers and layout algorithms need to understand my concept as well. If xmonad would simply abstract over StackSet, it would be very easy and transparent to do. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Oh, Common Lisp (CL) macros don't correspond to TH, but rather to regular functions in Haskell. We have first class actions together with lazy evaluation. What is code is data is code in CL is actions are first class values in Haskell. You only need TH when you need to generate something that is not first class, for example class instances. And many actions are first class values in CL. But there are many things that are not first class even in Haskell. Macros can manipulate lexical environments in many convenient ways, for example. Also, while you could make a function out of a complex iteration macro, it is guaranteed to be simpler to use. Remember that we're talking about very different paradigms. I can totally see how you would want and love macros in CL. In CL you encode your solution in such a way that using macros is the natural thing to do, and then lexical manipulation is probably something that comes in handy. In Haskell your encoding is entirely different, so you wouldn't use macros in the first place. Instead you would use non-strict higher-order functions together with type classes. Ah, so Haskell has no usable records without lenses? The standard record system is very limited, even though some language extensions try to improve it (without much success). However, you would most likely want to use lenses anyway, even if standard records were richer. Modern van Laarhoven lenses are a powerful abstraction for accessing data structures, mainly because a lens does not necessarily correspond to a certain concrete field (it can correspond to many fields or to a logical alternate view of certain data) and also because both lenses and lens operators are first class values. Where `temps` is a list of temperatures in degrees Celsius, the following is that list with three degrees Fahrenheit added to each item: (traverse . fahrenheit +~ 3) temps The thing in parentheses is a function that takes any traversable data structure (e.g. lists or trees), interprets its values as temperatures, applies a Fahrenheit view and then adds 3. The result is the modified data structure (i.e. it's pure). The following is the same function, except that it only adds if the original temparature is greater than 10. All lower temperatures remain untouched: traverse . filtered ( 10) . fahrenheit +~ 3 Finally as said lenses and lens operators are first class, so you can take them as arguments, return them as results and put them into data structures. Let `fields` be a list of lenses. Then the following is a list of lenses pointing deeper into the individual data structures (into the `field` subfield of whatever each lens points to): (traverse %~ (. field)) fields That's why we love lenses. They are more than just a recovery from our lack of a decent record system. And they are defined in plain Haskell, just to show you how far we can go without macros. =) signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Also the Nix model allows us to compile all our scripts easily (just apply a function), which might hold some benefit in terms of startup and switch times. There is little reason to use interpreted scripts when you have a fast compiler. So would you say that this is preferable to the shell-monad idea? Yes. Even when compiling a Haskell DSL to a shell script you need to compile the DSL itself first into a program that can output the script. If you are going to compile anyway, just compile the source language to a runnable binary in the first place. One huge benefit of that is that you can use the libraries and abstractions of the source language. As a simple example by compiling to Bash you give up the option of using Haskell's concurrency, exception handling, etc. And those two are particularly difficult to translate to Bash, or pretty much every other shell. I'd definitely say that NixOS is the most state-of-the-art GNU+Linux distribution in existence, [...] To be fair, there is also the GNU OS, which uses Guix, although the underlying ideas and build system (nix-daemon) are the same. [...] for people who rarely use computers, the potential difference is a lot lower, so UI changes should not be forced upon them.) I think it is important to define your target audience. If you are specifically targetting, as you call them, computer illiterates or people who rarely use computers, it is entirely reasonable to offer them an easy, slowly evolving UI. However, for the general public I would say that our current state of the art in UIs is so broken that the faster we move on the better for humanity. For example anyone who tells me that touch screens are intuitive does not understand the word *intuitive*. Hint: It does not mean pictures, nor does it mean pointing. The same holds for virtual UIs that we access through HIDs. For a concrete example just try to use style sheets *and* be productive at the same time in your office suite of choice (don't worry, they all suck). Try to handle hundreds of e-mails per day (*handle*, not skim!) in multiple mailboxes *and* use less than 50% of your work time for dealing with e-mail in any MUA (yes, I'm including mutt and Emacs). Now don't get me wrong. You do have a point there. If a UI was perfectly reasonable and has been replaced by something less reasonable, I can totally understand your dissatisfaction. That does happen from time to time when marketing people try to be smart. But if the sole reason that you are unhappy is because you have to learn something new, then you shouldn't suggest moving to purely functional languages for scripting. Remember that contributors are humans as well, many of them will face having to learn something new and nontrivial, and some of them will probably be just as angry as you are when your UI has been replaced without the option to go back. Again don't get me wrong. I suggest that we do it, as long as we think that we're moving along the right track. Innovation will almost by necessity cause some dissatisfaction. I'm really just saying that there is not much difference between innovation in programming languages (programmers are humans) and user experience (users are humans). For some of them innovation will be a problem in both cases. Either you choose to respect that, or you choose to move on regardless. It depends on your target audience. I'm also only interested in the pure-functional languages. I'm not interested in so-called ‘multiparadigm’ functional/imperative languages like Scheme as this does not provide the deterministic purity guarantees that pure-functional languages are based-on. I would love to use Haskell for everything, but it's simply not a realistic option. Currently GHC is practically our only compiler. It is huge, compiling takes time, etc. We can fix all of these things, but we haven't so far and GHC will not get smaller or faster any time soon. Let me clarify: GHC is not slow per se, if you consider that Haskell has an extremely high signal/noise ratio, not just in syntax, but especially in semantics. Two lines of Haskell can easily *mean a lot* (i.e. encode a program that does lots of things or very complicated things). If we measure by time spent per semantic content, then GHC is lightning-fast. However, that measure is only interesting for larger projects. For small scripts the measure time spent per line of code counts, and GHC does not perform too well there. The other static functional languages I have tried were either too noisy, too immature or did not provide a reasonable FFI. Things will improve and new options will pop up, but right now our choices are limited. True, but the idea is to minimise impure code. The documentation and tutorials of pure languages encourage the practice of factoring-out any necessary impure code and writing most code to be pure. Can the same be said about multiparadigm languages? You may need to adjust your
Re: [Nix-dev] Use Haskell for Shell Scripting
To be fair, there is also the GNU OS, which uses Guix, although the underlying ideas and build system (nix-daemon) are the same. [...] As such, it's probably best for me to not talk about GNU OS, Guix, and Guile until I get the time/willpower to explain why my viewpoint against that project is not malicious and why NixOS is – perhaps counterintuitively to some libre software supporters – more beneficial to the software freedom movement. Do yourself a favour by not getting into that kind of argument. They see benefit in their way of doing things, and I would strongly support their project. Both GNU OS and NixOS are heading into a much better direction than pretty much all other distributions in my personal view, and I would happily encourage them to carry on. At some point in time we will benefit from each other, and in fact I see a huge benefit even for NixOS in the sole existence of GNU OS, if only to have some GNU people following the functional distribution approach. If nothing else the fact that two projects happily follow the same idea may well indicate to some people that we're on the right track. We as in the GNU OS and NixOS people. In short: Better stop arguing against them, regardless of what your reasons are. The only thing you can gain by that is a week of heated flamewars with no conclusion other than that they will think that NixOS people are jerks. I'd prefer us to work together instead of against each other. Nevertheless, I still think that human interface choice is important, and XMonad is an example of the original point that I was trying to get at. It is a classic user interface, a tiling window manager, using a pure-functional language. Just because something is written using modern techniques doesn't mean to say that the user interface itself is ‘modern’. I use the same combination (xmonad + taffybar) and could complain all day long about it. Of course this is constructive criticism, and I'm an idealist to some extent, but still there is a lot of room for improvement. For example xmonad is too rigid. It has a fixed data structure that corresponds directly to what is displayed on each screen. Workspace names are strings, which is hugely inconvenient. Something like tag-based volatile workspaces are not possible, although with some really ugly (and slow) hacks you could do it. In the ideal graphical environment I wouldn't see any reason to close or move a single window -- ever. Xmonad gets closer, but is still far away. ‘multiparadigm’ is ambiguous as to what multiple paradigms that refers to, but I clarified that by saying “functional/imperative”. I did mean that Haskell supports imperative programming just as well as it does support declarative programming. Some people say that it's the best imperative language out there. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
On 09/02/15 15:22, Ertugrul Söylemez wrote: Also the Nix model allows us to compile all our scripts easily (just apply a function), which might hold some benefit in terms of startup and switch times. There is little reason to use interpreted scripts when you have a fast compiler. So would you say that this is preferable to the shell-monad idea? Yes. Even when compiling a Haskell DSL to a shell script you need to compile the DSL itself first into a program that can output the script. If you are going to compile anyway, just compile the source language to a runnable binary in the first place. One huge benefit of that is that you can use the libraries and abstractions of the source language. As a simple example by compiling to Bash you give up the option of using Haskell's concurrency, exception handling, etc. And those two are particularly difficult to translate to Bash, or pretty much every other shell. Okay, sure. Nevertheless, shell-monad could still come in handy for Grub scripts or something where I have no choice but to run shell scripts. :-D I'd definitely say that NixOS is the most state-of-the-art GNU+Linux distribution in existence, [...] To be fair, there is also the GNU OS, which uses Guix, although the underlying ideas and build system (nix-daemon) are the same. Last time that I talked about Guix on IRC, I seem to remember that Ludovic (civodul) declared that I was trolling and subsequently left the channel, which was not and is not my intention because I'm a keen libre software supporter and I accept that GNU OS is with good intentions. As such, it's probably best for me to not talk about GNU OS, Guix, and Guile until I get the time/willpower to explain why my viewpoint against that project is not malicious and why NixOS is – perhaps counterintuitively to some libre software supporters – more beneficial to the software freedom movement. [...] for people who rarely use computers, the potential difference is a lot lower, so UI changes should not be forced upon them.) I think it is important to define your target audience. If you are specifically targetting, as you call them, computer illiterates or people who rarely use computers, it is entirely reasonable to offer them an easy, slowly evolving UI. However, for the general public I would say that our current state of the art in UIs is so broken that the faster we move on the better for humanity. For example anyone who tells me that touch screens are intuitive does not understand the word *intuitive*. Hint: It does not mean pictures, nor does it mean pointing. The same holds for virtual UIs that we access through HIDs. For a concrete example just try to use style sheets *and* be productive at the same time in your office suite of choice (don't worry, they all suck). Try to handle hundreds of e-mails per day (*handle*, not skim!) in multiple mailboxes *and* use less than 50% of your work time for dealing with e-mail in any MUA (yes, I'm including mutt and Emacs). Now don't get me wrong. You do have a point there. If a UI was perfectly reasonable and has been replaced by something less reasonable, I can totally understand your dissatisfaction. That does happen from time to time when marketing people try to be smart. But if the sole reason that you are unhappy is because you have to learn something new, then you shouldn't suggest moving to purely functional languages for scripting. Remember that contributors are humans as well, many of them will face having to learn something new and nontrivial, and some of them will probably be just as angry as you are when your UI has been replaced without the option to go back. Again don't get me wrong. I suggest that we do it, as long as we think that we're moving along the right track. Innovation will almost by necessity cause some dissatisfaction. I'm really just saying that there is not much difference between innovation in programming languages (programmers are humans) and user experience (users are humans). For some of them innovation will be a problem in both cases. Either you choose to respect that, or you choose to move on regardless. It depends on your target audience. Sure, there isn't a distinct dividing line because, of course, the programming language can be seen as the developer's ultimate human interface to the computer, but what I was trying to say is that comparisons of human interfaces are considerably more subjective and personal than comparisons of programming techniques. However, this may be a false conclusion of the apparent deterioration of graphical user interfaces in Gnome, KDE, Firefox, Nautilus, and pretty much anything that focuses on the concept of ‘discoverability’ by removing features and preferences rather than improving their documentation and providing interactive demonstrations. Basically, these ‘modern’ interfaces are, generally by design, quicker to get the hang of but less efficient in the long-run
Re: [Nix-dev] Use Haskell for Shell Scripting
Maybe you need to script it properly? Maybe StumpWM is less rigid from the beginning, though (I use it and extended it for my needs, so I can probably answer your questions if you wonder about it; it is in Common Lisp, by default all the splits are manual, and there are many hooks to perform actiosn on events like window addition) Thanks! However, I'd better not switch to a WM that I wouldn't enjoy configuring. Also I think that I've bent xmonad pretty much to its limits and hit the abstraction wall. Nowadays my configuration is a whole cabalised package that I install via Nix. If you're interested, it's online [1]. The abstraction wall I hit is StackSet. It is highly sequential (workspaces are lists of windows, there is a mapping from screens to workspaces, etc.) and offers absolutely no choice to organise windows differently. What I mean by too rigid is having f :: Blah X - M () instead of f :: (SomeAppropriateClass f) = f X - M () thereby enforcing `Blah` instead of an `f` of my choice. [1]: http://hub.darcs.net/ertes-m/config/browse/myxmonad signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
On 09/02/15 19:56, Ertugrul Söylemez wrote: [...] In short: Better stop arguing against them, regardless of what your reasons are. [...] I'm not; I'm avoiding argument. Please don't make assumptions as to what my reasons are! Otherwise your mind is arguing ‘for me’, but not necessarily with the correct reasons and possibly in an unconstructive way which defeats the object of me trying to avoid the topic! Actually it's 2 unrelated topics that aren't specific to GNU OS, which I have avoided talking about in relation to GNU OS since 2014-12-05 because I want to be as constructive as possible for GNU OS (in other words, of all the things with these 2 issues, GNU OS is probably my absolute favourite), but being optimally constructive on such a complicated matter is very time consuming, and I currently think that it's not the best thing to focus my time on. So I'm avoiding the topic and trying to solve (relatively) easier problems. Roll-on ARM support! Let's get NixOS on open hardware! :-/ Nevertheless, I still think that human interface choice is important, and XMonad is an example of the original point that I was trying to get at. It is a classic user interface, a tiling window manager, using a pure-functional language. Just because something is written using modern techniques doesn't mean to say that the user interface itself is ‘modern’. I use the same combination (xmonad + taffybar) and could complain all day long about it. Of course this is constructive criticism, and I'm an idealist to some extent, but still there is a lot of room for improvement. For example xmonad is too rigid. It has a fixed data structure that corresponds directly to what is displayed on each screen. Workspace names are strings, which is hugely inconvenient. Something like tag-based volatile workspaces are not possible, although with some really ugly (and slow) hacks you could do it. In the ideal graphical environment I wouldn't see any reason to close or move a single window -- ever. Xmonad gets closer, but is still far away. What?!! That sounds very abstract and cool! Maybe esoteric. Can you elaborate? ‘multiparadigm’ is ambiguous as to what multiple paradigms that refers to, but I clarified that by saying “functional/imperative”. I did mean that Haskell supports imperative programming just as well as it does support declarative programming. Some people say that it's the best imperative language out there. Yes, but the documentation, tutorials, and community emphasise the pure-functional paradigm. Anyway, it doesn't stop at functional; I've been toying with the concept of relational programming (of which functional can be seen as a subset of). Functional is just the minimum bar for me. ;-) But wait, we seem to have lost the original thread! :-) So does pure-functional scripting for pure-functional packages sound like an appropriate placement? Best regards, James Haigh. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
On 30/01/15 16:02, Joe Hillenbrand wrote: http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html Time to replace all shell scripts in Nix with Haskell? No, certainly _now_ is way too early to replace _all_, but possibly _some_, and starting with just the functional programming packages. I've seen a couple of Haskell shells (e.g. Hell) since maybe about a year ago. They're on my todo list of things to switch to (just like NixOS was for me from 2013 to 2014). I would recommend using a Haskell shell as your main shell for some time before submitting scripts in it to a project that only has loose ties with Haskell. It would also be nice to wait for Haskell shell users and documentation to increase first because currently, if someone is to look at a Haskell shell script who has not seen one before, it would not be so easy for them to get help with it. On the other hand, Nix expressions that relate specifically to Haskell packages may be an appropriate place for such scripts because, well, people using Haskell are going to have less of a learning curve with them and would better appreciate the advantages. I am though concerned for energy efficiency. Increasing required computation doesn't just cost more / take longer, but also has greater environmental impact. It's a trade-off, but it should be kept in-mind. On 30/01/15 17:35, Joe Hillenbrand wrote: [...] Given those concerns another option could be shell-monad[1][2], which outputs shell script, so you get some of the safety benefits of Haskell with none of the overhead. Maybe it would be a good middle ground. [1] http://joeyh.name/blog/entry/shell_monad_day_3/ [2] http://hackage.haskell.org/package/shell-monad Wow yes, that's really quite interesting!!! On 01/02/15 00:24, Ertugrul Söylemez wrote: What about other languages as Python, Perl etc.? I know it is against our purity standards, but they are a far superior to Bash scripting. Well, that's the current state of the art. They are both used in Nixpkgs and some Nix-related tools. They are an improvement over Bash scripting, but I believe we might as well go all the way and use a functional language. Yes, I agree. If we're going to use a higher-level language, it should at least make it into the pure-functional paradigm level of abstraction. I see breaking legacy as being akin to forming lightning strikes; there has to be enough potential difference (advancement) to break-down the electrical insulation (difficulty in migration) and initiate the electrostatic discharge (migration). Switching from Bash to Python doesn't have so much appeal to me anymore since I've already been moving from Python to the functional paradigm since 2012. Also the Nix model allows us to compile all our scripts easily (just apply a function), which might hold some benefit in terms of startup and switch times. There is little reason to use interpreted scripts when you have a fast compiler. So would you say that this is preferable to the shell-monad idea? On 30/01/15 16:36, Domen Kožar wrote: If you want to impose on people to learn Haskell and Nix to contribute, you're going to end up in a lonely island. Remember, Nix tries to be approachable to everyone and that's why it's minimal and simple. A lot of developers do realize that bash is terrible, but it wasn't replaced yet exactly for that reason. Legacy matters. Well, if I cared too much about legacy, I wouldn't be using NixOS! :-D I'd definitely say that NixOS is the most state-of-the-art GNU+Linux distribution in existence, albeit a little lacking of hardware support and package ecosystem, but this is improving fast! (I must note though, that there are 2 cases in which legacy is particularly important: human interfaces, and hardware. This is because those 2 things are not a simple matter of changing software. Human interfaces are a very personal thing and I find it frustrating when they change continually, with no preference for previous behaviour, or even that preferences are removed. I'm not alone in this frustration; UI change is particularly harsh on computer illiterate who struggle to learn 1 interface as it is. Hardware is obviously costly to upgrade, contributes to electronic waste, and again, their human interface devices are very personal preferences. I'm using ThinkPad X60 Tablets largely because I like pointing stick mice, hate touchpads, like the ThinkPad keyboard, and like the inductive tablet screen and stylus. Whereas with non-human-interface software, it's possible to break legacy and achieve state-of-the-art efficiency, maintainability, reliability, etc. without any cost to the end user. I'm not saying that you can't have state-of-the-art hardware or user interfaces, it's just that, to use the lightning analogy again, the dielectric strength for the electrical insulator is a lot higher and for people who rarely use computers, the potential difference is a lot lower, so UI changes should not be
Re: [Nix-dev] Use Haskell for Shell Scripting
In short: Better stop arguing against them, [...] I'm not; [...] Alright. =) In the ideal graphical environment I wouldn't see any reason to close or move a single window -- ever. Xmonad gets closer, but is still far away. What?!! That sounds very abstract and cool! Maybe esoteric. Can you elaborate? It's not that esoteric. Think about the average 2013 laptop or PC with plenty of RAM. When you're done with a certain task, you close its window, simply because you're used to that and perhaps because you draw a relationship to the physical world, where you prefer your desk to be clean and organised. The truth is that a virtual desktop does not really (have to) correspond to a real one. There is no technical reason to close the window other than the limits imposed by your amount of RAM and swap. In fact you shouldn't close windows, unless you're absolutely sure that you will never need them again. Most of the windows you close you just find yourself reopening again later, going through all the procedures from firing up a program to navigating to a file to scrolling to the part you want to view or edit. It's not *much* work, but it's repetetive and unnecessary. Think of the average Windows user, who is used to the fact that there is only one desktop. When they need to suspend a task to temporarily work on another one, they start to close or minimise windows, only to have to find and recall all of them later. This takes a considerable amount of time, probably wasting a good ten minutes before you can get back up to speed again. Why? Because it's the most unnatural thing you can do. When you need to interrupt your current work in the physical world, do you drop everything to the floor or stuff everything back into the drawer? Perhaps you do the first few times, but then you get a second desk or a larger one. That's probably the number one reason why Windows users generally have at least two screens and would prefer to have more. So what's the solution? Simple: Workspaces must be cheap, dynamic and extremely easy to manage. There should not be a rigid mapping between workspaces and windows. Windows should easily be able to belong to multiple workspaces. A generalised xmonad could do it, but the current one can't. I'd be happy to discuss this further, but I'm afraid we're getting way out of topic. =) signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Thanks! However, I'd better not switch to a WM that I wouldn't enjoy configuring. Also I think that I've bent xmonad pretty much to its limits and hit the abstraction wall. Nowadays my configuration is a whole cabalised package that I install via Nix. If you're interested, it's online [1]. If you hit an abstraction wall, maybe you would actually enjoy doing what you originally wanted with access to lower-level abstraction. For xmonad StackSet is the lowest level. Using something different amounts to writing a new window manager, a generalisation of xmonad. Well, StumpWM allows arbitrary splits, very useful for Lazarus, Gimp, etc. Oh, this is not about splits. Xmonad allows that, too, via layouts. This is about the core data structure holding the current window configuration (the associations between windows and workspaces, and between workspaces and screens). It is a core piece of the window manager and cannot be modified by an addon. Haskell allows to abstract over this data structure easily, i.e. quantify over what is currently StackSet. The problem is: Xmonad does not do that. There is no inherent technical difficulty in doing it, it just doesn't do it. The equivalent in C++ would be to use templates instead of concrete functions, but there is no good translation for type classes. You really want type classes for this kind of thing. Maybe you should try Ratpoison and give it commands from a Haskell decision-making piece of code? Ratpoison also has arbitrary splits, it is simpler than StumpWM and can do way less. Driving StumpWM externally shoud also be easy, although with larger overhead. Generalising the xmonad source code would probably work better for me, because it allows me to stay in Haskell land and use types the way I'm used to. Also I don't believe that a WM written in C can have what I'm looking for at all (abstracting over the core data structure). It would have to be implemented by horrible pointer magic, and I don't want to touch that, even if it were there. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
The Typed Racket idea is pretty good. I would point out, however, that it only addresses the type-safety concern Joe brought up; not purity. It's still pretty idiomatic Typed Racket to use side-effects and mutation from otherwise pure code. On Sun, Feb 1, 2015 at 12:57 AM, Michael Raskin 7c6f4...@mail.ru wrote: Chicken or Scheme are not at all what at all what I was suggesting as they offer nothing in the way of purity or type-safety, which are the primary motivation for suggesting Haskell. Typed Racket? (Racket, as it got named when PLT Scheme developers decided they added too much into Scheme and need to rename) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
If only we had a way to produce multiple outputs from a single package... :) On Jan 31, 2015, at 07:22, Ertugrul Söylemez ert...@gmx.de wrote: There should be a pure library derivation and a separate compiler derivation. The former should be as small as possible. Ideally there would be one derivation per library. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
If only we had a way to produce multiple outputs from a single package... :) We have. The `derivation` function supports producing multiple outputs, and I'm sure that `mkDerivation` forwards this ability. Greets, Ertugrul signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Yeah, was kidding around! On Jan 31, 2015, at 10:47, Ertugrul Söylemez ert...@gmx.de wrote: If only we had a way to produce multiple outputs from a single package... :) We have. The `derivation` function supports producing multiple outputs, and I'm sure that `mkDerivation` forwards this ability. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Yes, I’m planning to work on multiple outputs for ghc soon :) On Jan 31, 2015, at 3:55 PM, Daniel Peebles pumpkin...@gmail.com wrote: Yeah, was kidding around! On Jan 31, 2015, at 10:47, Ertugrul Söylemez ert...@gmx.de wrote: If only we had a way to produce multiple outputs from a single package... :) We have. The `derivation` function supports producing multiple outputs, and I'm sure that `mkDerivation` forwards this ability. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Yes, I’m planning to work on multiple outputs for ghc soon :) Great! I'm looking forward to that. =) signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
At Sat, 31 Jan 2015 13:22:09 +0100, Ertugrul Söylemez wrote: [...] I have actually experimented with using Haskell (and a few other FP languages) as a substitute for shells. [...] You might be interested why Curry didn't work. Simple: I couldn't figure out how to write a program. Actually I went through the whole tutorial, did all the exercises (they aren't really difficult to a Haskell programmer) and then skimmed through the whole PAKCS manual. I could write extremely elegant algorithmic code and was quite amazed at the beauty of this language, even compared to Haskell. But in the end I still didn't know how to turn all this beautiful Curry code into an executable file that I can run without invoking PAKCS explicitly. Something with a shebang or ideally something binary. It would probably be possible to write wrapper scripts, but let's just wait until one of the implementations becomes mature enough for systems programming. Curry is indeed a beautiful language, and is essentially a conservative extension of Haskell. I am surprised that more Haskell folk have not adopted it. PAKCS compiles Curry to Prolog (typically SICStus), which drags in the Prolog system. To get a binary executable, a better choice would be MCC (compiles Curry to native code) or KiCS2 (compiles Curry to Haskell, which can go into ghc): http://www-ps.informatik.uni-kiel.de/currywiki/implementations/overview Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
2015-01-31 22:24 GMT-02:00 Ertugrul Söylemez ert...@gmx.de: What about other languages as Python, Perl etc.? I know it is against our purity standards, but they are a far superior to Bash scripting. Well, that's the current state of the art. They are both used in Nixpkgs and some Nix-related tools. They are an improvement over Bash scripting, but I believe we might as well go all the way and use a functional language. Also the Nix model allows us to compile all our scripts easily (just apply a function), which might hold some benefit in terms of startup and switch times. There is little reason to use interpreted scripts when you have a fast compiler. So, Chicken appears to be a good choice: it can be both interpreted and compiled, very fast and with little overhead. And it can be easily debugged - it's functional, after all! I think Haskell is as much as overkiller - there is even a project about it: Nix Evaluator in Haskell[1]. It is easier to use a less ambitious and more funny language (in the Python sense of funny programming). What about to start a project to implement Chicken as script supporting language for Nix? I would like to help! 1 - http://lists.science.uu.nl/pipermail/nix-dev/2014-July/013624.html ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
What about other languages as Python, Perl etc.? I know it is against our purity standards, but they are a far superior to Bash scripting. Well, that's the current state of the art. They are both used in Nixpkgs and some Nix-related tools. They are an improvement over Bash scripting, but I believe we might as well go all the way and use a functional language. Also the Nix model allows us to compile all our scripts easily (just apply a function), which might hold some benefit in terms of startup and switch times. There is little reason to use interpreted scripts when you have a fast compiler. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Guix is an already existing Nix implementation in Guile. Let's take the other path.Haskell, since the issue of closures is apparently simple. On Sat, Jan 31, 2015 at 10:22 PM, Ertugrul Söylemez ert...@gmx.de wrote: At this current point in time, GHC is packaged in a poor manner, with GHC being unbelievably huge. Dynamic linking is the answer, which isn't done by default. I have actually experimented with using Haskell (and a few other FP languages) as a substitute for shells. It is feasible if you disable dynamic linking. The non-Haskell libraries are still linked dynamically, but the reference to the GHC derivation is then gone. This brings the closure of a Haskell hello-world script from a huge 1.1 GiB down to a mere 131 MiB (on my x86_64 system), which makes it on par with shell scripts. However, static linking is probably not a good idea. The resulting scripts are on the order of megabytes and can quickly approach a few tens of them. To really fix this and make Haskell viable as a shell substitute we need to split the GHC derivation. There should be a pure library derivation and a separate compiler derivation. The former should be as small as possible. Ideally there would be one derivation per library. The other languages I have tried are Scheme (via Chicken), Curry (via PAKCS), SML (via mlton) and Idris. Before I present my results, let me clarify what I think a script is: It is a string that I can run through a simple Nix function, which gives me a derivation that contains a runnable version of that string, either binary or shebanged. This derivation pulls a reasonably sized closure along with it. I can choose to combine many such runnable scripts to a single derivation using buildEnv, which is often very useful. In other words: For the language blah there is a simple, deterministic, unconfigurable function that would have the following signature in a hypothetical typed Nix: blahScript : String - Derivation This function can be a special case of a slightly more powerful function that takes a directory and a main entry point, because if we choose to use a better language, we might as well choose to utilise its module system, if it has one, for some of our larger scripts. Now to my results: All of the above languages, except Curry, work more or less, if all you need to do is to start programs or move files around. As soon as you need to do operating-system-specific stuff (e.g. `unshare` on Linux) it gets less juicy, because unless someone has written a nice high-level library you need to touch the FFI. Chicken Scheme worked best for that, because rather than trying to model the syscall in the language, you can just dump C code into it. Not a nice and clean solution, but a working one for the many cases when you just need to -- you know -- get stuff done. Haskell works, because lots of the OS bindings can be found on Hackage, including Linux-specific libraries. But it does require a slightly more expressive 'haskellScriptWith' function. You need to be able to tell it what you depend on. SML works and produces surprisingly small executables. It loses at the library end, because there aren't many OS-specific libraries around (or I couldn't find them). Also some of the advanced FFI tooling that I'm used to from Haskell seems to be missing. Finally I would say that the syntax is too verbose for quick scripting (but that's subjective -- I have seen people use VB.NET for scripting). You might be interested why Curry didn't work. Simple: I couldn't figure out how to write a program. Actually I went through the whole tutorial, did all the exercises (they aren't really difficult to a Haskell programmer) and then skimmed through the whole PAKCS manual. I could write extremely elegant algorithmic code and was quite amazed at the beauty of this language, even compared to Haskell. But in the end I still didn't know how to turn all this beautiful Curry code into an executable file that I can run without invoking PAKCS explicitly. Something with a shebang or ideally something binary. It would probably be possible to write wrapper scripts, but let's just wait until one of the implementations becomes mature enough for systems programming. Finally there is Idris. It is a beautiful language that comes with reasonable editor integration and a lightweight syntax. It compiles to executable binary code and has a carefully designed yet useful FFI. Sounds good for scripting. On the other hand it is very young and documentation is far from mature. Not that I would mind its youth, but I do mind the barrier to entry at this point. At the very least when other authors don't understand my code, it should be reasonably obvious where to look for answers. Also the library landscape is very flat, so bootstrapping might use most of your time, if you choose to use Idris for systems-level scripting at this point.
Re: [Nix-dev] Use Haskell for Shell Scripting
2015-01-31 10:22 GMT-02:00 Ertugrul Söylemez ert...@gmx.de: At this current point in time, GHC is packaged in a poor manner, with GHC being unbelievably huge. Dynamic linking is the answer, which isn't done by default. I have actually experimented with using Haskell (and a few other FP languages) as a substitute for shells. It is feasible if you disable dynamic linking. The non-Haskell libraries are still linked dynamically, but the reference to the GHC derivation is then gone. This brings the closure of a Haskell hello-world script from a huge 1.1 GiB down to a mere 131 MiB (on my x86_64 system), which makes it on par with shell scripts. However, static linking is probably not a good idea. The resulting scripts are on the order of megabytes and can quickly approach a few tens of them. To really fix this and make Haskell viable as a shell substitute we need to split the GHC derivation. There should be a pure library derivation and a separate compiler derivation. The former should be as small as possible. Ideally there would be one derivation per library. The other languages I have tried are Scheme (via Chicken), Curry (via PAKCS), SML (via mlton) and Idris. Before I present my results, let me clarify what I think a script is: It is a string that I can run through a simple Nix function, which gives me a derivation that contains a runnable version of that string, either binary or shebanged. This derivation pulls a reasonably sized closure along with it. I can choose to combine many such runnable scripts to a single derivation using buildEnv, which is often very useful. In other words: For the language blah there is a simple, deterministic, unconfigurable function that would have the following signature in a hypothetical typed Nix: blahScript : String - Derivation This function can be a special case of a slightly more powerful function that takes a directory and a main entry point, because if we choose to use a better language, we might as well choose to utilise its module system, if it has one, for some of our larger scripts. Now to my results: All of the above languages, except Curry, work more or less, if all you need to do is to start programs or move files around. As soon as you need to do operating-system-specific stuff (e.g. `unshare` on Linux) it gets less juicy, because unless someone has written a nice high-level library you need to touch the FFI. Chicken Scheme worked best for that, because rather than trying to model the syscall in the language, you can just dump C code into it. Not a nice and clean solution, but a working one for the many cases when you just need to -- you know -- get stuff done. Haskell works, because lots of the OS bindings can be found on Hackage, including Linux-specific libraries. But it does require a slightly more expressive 'haskellScriptWith' function. You need to be able to tell it what you depend on. SML works and produces surprisingly small executables. It loses at the library end, because there aren't many OS-specific libraries around (or I couldn't find them). Also some of the advanced FFI tooling that I'm used to from Haskell seems to be missing. Finally I would say that the syntax is too verbose for quick scripting (but that's subjective -- I have seen people use VB.NET for scripting). You might be interested why Curry didn't work. Simple: I couldn't figure out how to write a program. Actually I went through the whole tutorial, did all the exercises (they aren't really difficult to a Haskell programmer) and then skimmed through the whole PAKCS manual. I could write extremely elegant algorithmic code and was quite amazed at the beauty of this language, even compared to Haskell. But in the end I still didn't know how to turn all this beautiful Curry code into an executable file that I can run without invoking PAKCS explicitly. Something with a shebang or ideally something binary. It would probably be possible to write wrapper scripts, but let's just wait until one of the implementations becomes mature enough for systems programming. Finally there is Idris. It is a beautiful language that comes with reasonable editor integration and a lightweight syntax. It compiles to executable binary code and has a carefully designed yet useful FFI. Sounds good for scripting. On the other hand it is very young and documentation is far from mature. Not that I would mind its youth, but I do mind the barrier to entry at this point. At the very least when other authors don't understand my code, it should be reasonably obvious where to look for answers. Also the library landscape is very flat, so bootstrapping might use most of your time, if you choose to use Idris for systems-level scripting at this point. The most viable options seem to be Chicken Scheme and Haskell. Both are well documented and have a usable FFI. Chicken produces much smaller executables,
Re: [Nix-dev] Use Haskell for Shell Scripting
Curry is indeed a beautiful language, and is essentially a conservative extension of Haskell. I am surprised that more Haskell folk have not adopted it. Well, it does lack quite a few things right now, including on the language level. For example its way to deal with ad-hoc polymorphism is very ugly, because it has no type classes yet: (==) :: a - a - Bool Constraint programming can be done reasonably in Haskell, it just won't be as pretty and implicit as in Curry. So I can live with Haskell's lack of built-in constraint programming, but I can't live with Curry's lack of type classes. In other words, there is still a lot of room for improvement, and it caught my attention so much that I will definitely check from time to time for Curry news. The perfect programming language in my view would combine the best of Agda, Curry, Haskell, Idris and this crazy data flow language whose name I forgot (it has negative and reciprocal types representing lack of information). PAKCS compiles Curry to Prolog (typically SICStus), which drags in the Prolog system. To get a binary executable, a better choice would be MCC (compiles Curry to native code) or KiCS2 (compiles Curry to Haskell, which can go into ghc): PAKCS was the only implementation I could find in Nixpkgs, and it was sufficient to get a feeling for the language. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
, copy-nix-closure to copy it to the machine I want to run it on, and on that remote machine run `nix-env -i`. In the derivation for the package I've used the `hiPrio` function to make this new package a higher priority. When I use the nix-repl and import and check the value, I can see that the meta.priority is indeed set to -10 as it should be. But when `nix-env -i` is run it still complains about the conflict. Is there a way to check the priority of something in the nix-store? Any ideas why the priority is being ignored and/or lost in this process? Am there something wrong in my process? -- next part -- An HTML attachment was scrubbed... URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150131/cb913c27/ attachment-0001.html -- Message: 5 Date: Sat, 31 Jan 2015 20:51:37 + From: Shea Levy s...@shealevy.com Subject: Re: [Nix-dev] Use Haskell for Shell Scripting To: Daniel Peebles pumpkin...@gmail.com Cc: nix-dev nix-dev@lists.science.uu.nl Message-ID: 1209c510-6abc-4581-9c97-da325d0f4...@shealevy.com Content-Type: text/plain; charset=utf-8 Yes, I?m planning to work on multiple outputs for ghc soon :) On Jan 31, 2015, at 3:55 PM, Daniel Peebles pumpkin...@gmail.com wrote: Yeah, was kidding around! On Jan 31, 2015, at 10:47, Ertugrul S?ylemez ert...@gmx.de wrote: If only we had a way to produce multiple outputs from a single package... :) We have. The `derivation` function supports producing multiple outputs, and I'm sure that `mkDerivation` forwards this ability. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Message: 6 Date: Sat, 31 Jan 2015 22:03:50 +0100 From: Ertugrul S?ylemez ert...@gmx.de Subject: Re: [Nix-dev] Use Haskell for Shell Scripting To: Shea Levy s...@shealevy.com, Daniel Peebles pumpkin...@gmail.com Cc: nix-dev nix-dev@lists.science.uu.nl Message-ID: m4bnleslvt.fsf@deimos.Speedport_W_723V_1_36_000 Content-Type: text/plain; charset=utf-8 Yes, I?m planning to work on multiple outputs for ghc soon :) Great! I'm looking forward to that. =) -- 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/20150131/30b8da8f/ attachment-0001.bin -- Message: 7 Date: Sun, 01 Feb 2015 08:59:13 +1100 From: Tim Barbour t...@categorical.net Subject: Re: [Nix-dev] Use Haskell for Shell Scripting To: Ertugrul S?ylemez ert...@gmx.de Cc: nix-dev nix-dev@lists.science.uu.nl Message-ID: 87r3ualiha.wl-...@categorical.net Content-Type: text/plain; charset=ISO-8859-1 At Sat, 31 Jan 2015 13:22:09 +0100, Ertugrul S?ylemez wrote: [...] I have actually experimented with using Haskell (and a few other FP languages) as a substitute for shells. [...] You might be interested why Curry didn't work. Simple: I couldn't figure out how to write a program. Actually I went through the whole tutorial, did all the exercises (they aren't really difficult to a Haskell programmer) and then skimmed through the whole PAKCS manual. I could write extremely elegant algorithmic code and was quite amazed at the beauty of this language, even compared to Haskell. But in the end I still didn't know how to turn all this beautiful Curry code into an executable file that I can run without invoking PAKCS explicitly. Something with a shebang or ideally something binary. It would probably be possible to write wrapper scripts, but let's just wait until one of the implementations becomes mature enough for systems programming. Curry is indeed a beautiful language, and is essentially a conservative extension of Haskell. I am surprised that more Haskell folk have not adopted it. PAKCS compiles Curry to Prolog (typically SICStus), which drags in the Prolog system. To get a binary executable, a better choice would be MCC (compiles Curry to native code) or KiCS2 (compiles Curry to Haskell, which can go into ghc): http://www-ps.informatik.uni-kiel.de/currywiki/implementations/overview Tim The nixpkgs expression for PAKCS uses SWI prolog, and PAKCS has an option for producing a wrapper that calls swi to execute your program. With this you can use PAKCS for scripting in more or less the same way as perl, php, bash, python, nodejs etc For example: [kkallio@eka:scratch]$ cat hello.curry main :: IO () main = putStrLn Hello world! [kkallio@eka:scratch]$ pakcs :load hello :save :quit [1 of 2] Skipping Prelude ( /nix/store/9rbmp69y6mc578y7iwan8ywn51lf77iz- pakcs-1.11.4/pakcs/lib/Prelude.curry, /nix/store/9rbmp69y6mc578y7iwan8ywn51lf77iz- pakcs-1.11.4
Re: [Nix-dev] Use Haskell for Shell Scripting
Chicken or Scheme are not at all what at all what I was suggesting as they offer nothing in the way of purity or type-safety, which are the primary motivation for suggesting Haskell. On Sat, Jan 31, 2015 at 8:12 PM, Anderson Torres torres.anderson...@gmail.com wrote: 2015-01-31 22:24 GMT-02:00 Ertugrul Söylemez ert...@gmx.de: What about other languages as Python, Perl etc.? I know it is against our purity standards, but they are a far superior to Bash scripting. Well, that's the current state of the art. They are both used in Nixpkgs and some Nix-related tools. They are an improvement over Bash scripting, but I believe we might as well go all the way and use a functional language. Also the Nix model allows us to compile all our scripts easily (just apply a function), which might hold some benefit in terms of startup and switch times. There is little reason to use interpreted scripts when you have a fast compiler. So, Chicken appears to be a good choice: it can be both interpreted and compiled, very fast and with little overhead. And it can be easily debugged - it's functional, after all! I think Haskell is as much as overkiller - there is even a project about it: Nix Evaluator in Haskell[1]. It is easier to use a less ambitious and more funny language (in the Python sense of funny programming). What about to start a project to implement Chicken as script supporting language for Nix? I would like to help! 1 - http://lists.science.uu.nl/pipermail/nix-dev/2014-July/013624.html ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
At this current point in time, GHC is packaged in a poor manner, with GHC being unbelievably huge. Dynamic linking is the answer, which isn't done by default. I have actually experimented with using Haskell (and a few other FP languages) as a substitute for shells. It is feasible if you disable dynamic linking. The non-Haskell libraries are still linked dynamically, but the reference to the GHC derivation is then gone. This brings the closure of a Haskell hello-world script from a huge 1.1 GiB down to a mere 131 MiB (on my x86_64 system), which makes it on par with shell scripts. However, static linking is probably not a good idea. The resulting scripts are on the order of megabytes and can quickly approach a few tens of them. To really fix this and make Haskell viable as a shell substitute we need to split the GHC derivation. There should be a pure library derivation and a separate compiler derivation. The former should be as small as possible. Ideally there would be one derivation per library. The other languages I have tried are Scheme (via Chicken), Curry (via PAKCS), SML (via mlton) and Idris. Before I present my results, let me clarify what I think a script is: It is a string that I can run through a simple Nix function, which gives me a derivation that contains a runnable version of that string, either binary or shebanged. This derivation pulls a reasonably sized closure along with it. I can choose to combine many such runnable scripts to a single derivation using buildEnv, which is often very useful. In other words: For the language blah there is a simple, deterministic, unconfigurable function that would have the following signature in a hypothetical typed Nix: blahScript : String - Derivation This function can be a special case of a slightly more powerful function that takes a directory and a main entry point, because if we choose to use a better language, we might as well choose to utilise its module system, if it has one, for some of our larger scripts. Now to my results: All of the above languages, except Curry, work more or less, if all you need to do is to start programs or move files around. As soon as you need to do operating-system-specific stuff (e.g. `unshare` on Linux) it gets less juicy, because unless someone has written a nice high-level library you need to touch the FFI. Chicken Scheme worked best for that, because rather than trying to model the syscall in the language, you can just dump C code into it. Not a nice and clean solution, but a working one for the many cases when you just need to -- you know -- get stuff done. Haskell works, because lots of the OS bindings can be found on Hackage, including Linux-specific libraries. But it does require a slightly more expressive 'haskellScriptWith' function. You need to be able to tell it what you depend on. SML works and produces surprisingly small executables. It loses at the library end, because there aren't many OS-specific libraries around (or I couldn't find them). Also some of the advanced FFI tooling that I'm used to from Haskell seems to be missing. Finally I would say that the syntax is too verbose for quick scripting (but that's subjective -- I have seen people use VB.NET for scripting). You might be interested why Curry didn't work. Simple: I couldn't figure out how to write a program. Actually I went through the whole tutorial, did all the exercises (they aren't really difficult to a Haskell programmer) and then skimmed through the whole PAKCS manual. I could write extremely elegant algorithmic code and was quite amazed at the beauty of this language, even compared to Haskell. But in the end I still didn't know how to turn all this beautiful Curry code into an executable file that I can run without invoking PAKCS explicitly. Something with a shebang or ideally something binary. It would probably be possible to write wrapper scripts, but let's just wait until one of the implementations becomes mature enough for systems programming. Finally there is Idris. It is a beautiful language that comes with reasonable editor integration and a lightweight syntax. It compiles to executable binary code and has a carefully designed yet useful FFI. Sounds good for scripting. On the other hand it is very young and documentation is far from mature. Not that I would mind its youth, but I do mind the barrier to entry at this point. At the very least when other authors don't understand my code, it should be reasonably obvious where to look for answers. Also the library landscape is very flat, so bootstrapping might use most of your time, if you choose to use Idris for systems-level scripting at this point. The most viable options seem to be Chicken Scheme and Haskell. Both are well documented and have a usable FFI. Chicken produces much smaller executables, and programs are very memory-efficient. By design it compiles via C; because of that instead of providing a carefully designed FFI it
Re: [Nix-dev] Use Haskell for Shell Scripting
If you want to impose on people to learn Haskell and Nix to contribute, you're going to end up in a lonely island. Remember, Nix tries to be approachable to everyone and that's why it's minimal and simple. A lot of developers do realize that bash is terrible, but it wasn't replaced yet exactly for that reason. Legacy matters. On Fri, Jan 30, 2015 at 5:07 PM, Oliver Charles ol...@ocharles.org.uk wrote: Not sure if you're serious, but the last time we considered even rewriting the scripts in C, people were mostly against that. However, I guess with this the major opposition (can't read the source code easily) goes away, because you can still cat the scripts. However, I'd imagine that the startup overhead is now higher than bash, and the size of closures goes up a lot (you have to pull in the many hundreds of MB that GHC needs). So while it's a nice idea, I don't think it's practical to be done system wide - though I'm all for doing it locally! -- ocharles On Fri, Jan 30, 2015 at 4:02 PM, Joe Hillenbrand joehil...@gmail.com wrote: http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html Time to replace all shell scripts in Nix with Haskell? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
Not sure if you're serious, but the last time we considered even rewriting the scripts in C, people were mostly against that. However, I guess with this the major opposition (can't read the source code easily) goes away, because you can still cat the scripts. However, I'd imagine that the startup overhead is now higher than bash, and the size of closures goes up a lot (you have to pull in the many hundreds of MB that GHC needs). So while it's a nice idea, I don't think it's practical to be done system wide - though I'm all for doing it locally! -- ocharles On Fri, Jan 30, 2015 at 4:02 PM, Joe Hillenbrand joehil...@gmail.com wrote: http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html Time to replace all shell scripts in Nix with Haskell? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
On Fri, Jan 30, 2015 at 8:36 AM, Domen Kožar do...@dev.si wrote: If you want to impose on people to learn Haskell and Nix to contribute, you're going to end up in a lonely island. Remember, Nix tries to be approachable to everyone and that's why it's minimal and simple. I'll never buy the circular argument that Haskell's not popular because Haskell's not popular. I think people would be encouraged to learn Haskell if Nix was using it to great success. From what I've seen, a huge chunk of the existing Nix community are Haskellers because they understand the benefits of purity. I think if there is a clear benefit to a superior tool, it should be used, though I'm not entirely convinced there are a huge benefit to using Turtle. On Fri, Jan 30, 2015 at 5:07 PM, Oliver Charles ol...@ocharles.org.uk wrote: Not sure if you're serious... I'm not sure if I am either. I'm just curious what people think about the possibility. I'd imagine that the startup overhead is now higher than bash, and the size of closures goes up a lot (you have to pull in the many hundreds of MB that GHC needs). Given those concerns another option could be shell-monad[1][2], which outputs shell script, so you get some of the safety benefits of Haskell with none of the overhead. Maybe it would be a good middle ground. [1] http://joeyh.name/blog/entry/shell_monad_day_3/ [2] http://hackage.haskell.org/package/shell-monad ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
At this current point in time, GHC is packaged in a poor manner, with GHC being unbelievably huge. Dynamic linking is the answer, which isn't done by default. http://stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary Aloha, RK. On Sat, Jan 31, 2015 at 3:35 AM, Joe Hillenbrand joehil...@gmail.com wrote: On Fri, Jan 30, 2015 at 8:36 AM, Domen Kožar do...@dev.si wrote: If you want to impose on people to learn Haskell and Nix to contribute, you're going to end up in a lonely island. Remember, Nix tries to be approachable to everyone and that's why it's minimal and simple. I'll never buy the circular argument that Haskell's not popular because Haskell's not popular. I think people would be encouraged to learn Haskell if Nix was using it to great success. From what I've seen, a huge chunk of the existing Nix community are Haskellers because they understand the benefits of purity. I think if there is a clear benefit to a superior tool, it should be used, though I'm not entirely convinced there are a huge benefit to using Turtle. On Fri, Jan 30, 2015 at 5:07 PM, Oliver Charles ol...@ocharles.org.uk wrote: Not sure if you're serious... I'm not sure if I am either. I'm just curious what people think about the possibility. I'd imagine that the startup overhead is now higher than bash, and the size of closures goes up a lot (you have to pull in the many hundreds of MB that GHC needs). Given those concerns another option could be shell-monad[1][2], which outputs shell script, so you get some of the safety benefits of Haskell with none of the overhead. Maybe it would be a good middle ground. [1] http://joeyh.name/blog/entry/shell_monad_day_3/ [2] http://hackage.haskell.org/package/shell-monad ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
You linked to something from 2011. Since 7.8 (or perhaps earlier?), it's dynamically linked by default. On Fri, Jan 30, 2015 at 7:52 PM, Raahul Kumar raahul.ku...@gmail.com wrote: At this current point in time, GHC is packaged in a poor manner, with GHC being unbelievably huge. Dynamic linking is the answer, which isn't done by default. http://stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary Aloha, RK. On Sat, Jan 31, 2015 at 3:35 AM, Joe Hillenbrand joehil...@gmail.com wrote: On Fri, Jan 30, 2015 at 8:36 AM, Domen Kožar do...@dev.si wrote: If you want to impose on people to learn Haskell and Nix to contribute, you're going to end up in a lonely island. Remember, Nix tries to be approachable to everyone and that's why it's minimal and simple. I'll never buy the circular argument that Haskell's not popular because Haskell's not popular. I think people would be encouraged to learn Haskell if Nix was using it to great success. From what I've seen, a huge chunk of the existing Nix community are Haskellers because they understand the benefits of purity. I think if there is a clear benefit to a superior tool, it should be used, though I'm not entirely convinced there are a huge benefit to using Turtle. On Fri, Jan 30, 2015 at 5:07 PM, Oliver Charles ol...@ocharles.org.uk wrote: Not sure if you're serious... I'm not sure if I am either. I'm just curious what people think about the possibility. I'd imagine that the startup overhead is now higher than bash, and the size of closures goes up a lot (you have to pull in the many hundreds of MB that GHC needs). Given those concerns another option could be shell-monad[1][2], which outputs shell script, so you get some of the safety benefits of Haskell with none of the overhead. Maybe it would be a good middle ground. [1] http://joeyh.name/blog/entry/shell_monad_day_3/ [2] http://hackage.haskell.org/package/shell-monad ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
