7 ms·

Hell: A Haskell Shell

117 points by tikhonj 13y ago

st0neage 13y ago
Hell? This could be heaven! For everyone.
- CraigJPerry 13y ago
  >> ls *.* Vs. >> fmap (filter (isInfixOf ".")) ls' No sale!
  - st0neage 13y ago
    Actually that was meant to be a joke. Is that really a reason to downvote?
    - adamtulinius 13y ago
      Yes, this isn't reddit.
      - andrewflnr 13y ago
        Truly clever, relevant humor is perfectly acceptable. It's the cheap stuff that deserves to be downvoted. The post in question is, AFAICT, only guilty of making a relevant point in a slightly humorous manner.
  - chrisdone 13y ago
    Completely fair criticism. Obviously, I don't mean to continue writing such lengthy code on the command-line, but in order to feel out what's good enough, I need the shell. The brevity can come later. E.g. there's no reason ls "*.*" couldn't be defined, e.g. ls = run . ("ls " ++)
    - saidajigumi 13y ago
      I'd argue that even the double-quotes in `ls "."` are too much for normal usage. There have been many attempts at creating non POSIX-y shells based on various languages, but AFAICT it's a non-starter to require special syntax when running basic command lines. I'm mostly not writing shell scripts, I'm using a command line to interact with the system. As such, I want no barrier to running programs yet a lightweight way to leverage a "real" programming language. Redefining tools like `ls` seems like a red herring as well. I'm not against built-ins (they're necessary), but the Unix toolchain isn't going anywhere anytime soon. You'll still need to pull data out of git, logfiles, munch that data with external tools, etc. As such it's worth thinking about how to best bridge these worlds. If the shell environment can provide a better ls, that's fine, but I suspect it's a design bug if it feels like it needs the built-in for day-to-day usage. On "feel", it also feels like there should be a seamless syntactic protocol for post-POSIX shells, but I've yet to nail down how it would work. Straw-man requirements: - Absolutely no special syntax to run programs - Low-drama way to write "real code", i.e. native scripting language syntax. - Great integration via syntax, shell built-ins for working in Unix-y pipeline. - Replace powerful yet bizarre bash/zsh parameter constructs with better native language tools. By low-drama, think of the success of Markdown vs. HTML, TeX, etc. for markup. Not as powerful, but much easier to use for its use cases. IMO, this is the most powerful thing about the POSIX shells -- there's zero ceremony around running programs and dealing with I/O redirection. That's also the compromise, as things like quoting semantics get hairy. One way a post-POSIX shell could go is to retain this seamlessness while adding a touch more modality so that the worst problems of POSIX shells are eliminated. For example, multiple-quoting or re-quoting should never be needed, real data structures are both available and the default, etc. Anyhow, Hell looks like a fun experiment and sandbox. Enjoy!
      - hyperpape 13y ago
        I agree completely. I've been thinking about this a lot, and non-quoted strings strike me as an absolute requirement for anything that aims to replace the bourne shell and its descendants (as opposed to complementing them in the way that Perl/Python/Ruby do it). But obviously it's hard to have non quoted strings in a programming language. I need to play more with TCL (the one non sh-like language I know that does this) but I think even it has some very strange features that grow out of treating ordinary text as strings.
miga 13y ago
It is not a real shell, since it misses basic pipes. It is just a library for renaming system functions to their Bash-like names... Move on, and look at these: * http://hackage.haskell.org/package/Shellac http://hackage.haskell.org/package/Shellac * http://hackage.haskell.org/package/pipes-shell http://hackage.haskell.org/package/pipes-shell * http://hackage.haskell.org/package/HSH http://hackage.haskell.org/package/HSH * http://hackage.haskell.org/package/shellish http://hackage.haskell.org/package/shellish
- rtpg 13y ago
  I'm not sure of the types of the functions, but Haskell's arrow typeclass could do arrows in theory.
- lelf 13y ago
  > since it misses basic pipes To be fair, you don't actually need them lelf:~/srcs/hell$ reverse <$> pwd "lleh/scrs/flel/sresU/" But yes, right now it's just a bunch of renames.
- klrr 13y ago
  Might note this was "whipped this up in a few hours". I suspect this is just an experiment. But I think this might evolve into something serious, lots of interest was expressed in /r/haskell. On a serious side note, it doesn't need pipes since the shell utilities are wrapped as function which are composable in Haskell.
- gregwebs 13y ago
  The last 3 links are to shell-scripting libraries, which have a different goal than creating an interactive shell. I would recommend shelly, the library I created: https://hackage.haskell.org/package/shelly https://hackage.haskell.org/package/shelly
- maaku 13y ago
  Wouldn't pipes be implemented as monads (arrows)? I think it'd be defeating the point to bolt on a Bourne shell convention for Haskell shell, when there's a native capability to be used...
- 13y ago
marcosdumay 13y ago
A shell made in a pure functional language... It does not look apealing (the main use of a shell is to create side effects), but I'll sure try it.
- DanWaterworth 13y ago
  The main use of Haskell is to create side effects. It just does so in a principled, constrained manner.
- Hemospectrum 13y ago
  There's a misunderstanding at work here about how Haskell actually regards side effects. In a few words: It provides an API for declaring side effects, and forces you to use this API when chaining them together, but it does not refuse to acknowledge their existence. Haskell's reputation exaggerates how this API was less powerful, or missing altogether, in early versions of the language. But its reputation is not what you write programs in.
  - marcosdumay 13y ago
    No misunderstanding. I know Haskell, and I do like it. But monads (each one) are better constrained to a small part of your code, otherwise you negate all the power you gain by declaring the side effects. And the entire point of a shell is to do IO all over the place.
- Sirenos 13y ago
  sigh Functional languages are all about keeping side effects under control so that you can tell what will and what will not change the state of the system. Think of it as incorporating awareness of program state into the type-system of the language.
- deckiedan 13y ago
  As others have replied to you, I think you misunderstand what side effects & IO are. Imagine a "normal" shell type chain: ps -ef | grep 'elephant' | sort -nk2 >> logfile.txt neither `grep`, nor `sort` should have any side effects, and if they do, then you have potential for weird bugs later on. (imagine your / is mounted read only, and sort has a side effect of writing everything to a temp file. now suddenly this otherwise sane looking chain stops working). In the command, you have a single input, and a single output (which has a specific mode, append). Those are the only IO functions which you've specified, but you have no guarantee that anything else will not make a mess of things. The dream for "pure functional" shell scripting would be where the side effects are more obvious, and controllable, not to eliminate them.
sur 13y ago
There's also scsh, which uses Scheme: http://www.scsh.net/ http://www.scsh.net/
- klibertp 13y ago
  Unfortunately, on FreeBSD: ===> scsh-0.6.7 is marked as broken: fails to install on amd64. And I really wanted to play with it. Seems like I will have to help in Scsh reimplementation in Racket before I can do this.
- jfb 13y ago
  It's not much of an interactive shell, although it's perfectly cromulent for writing shell scripts.
eternalban 13y ago
See: http://www.haskell.org/haskellwiki/Simple_Unix_tools http://www.haskell.org/haskellwiki/Simple_Unix_tools & http://www.haskell.org/ghc/docs/7.6.2/html/libraries/base-4.6.0.1/src/System-Console-GetOpt.html http://www.haskell.org/ghc/docs/7.6.2/html/libraries/base-4.... ps: Haskell is such a Gloriously Happy Land, why make it "hell"?
- chrisdone 13y ago
  Read the page?
  - eternalban 13y ago
    "Irony" is a side effect. Haskell is pure .. :P
- ChickeNES 13y ago
  I feel like "hell" is a perfect description for trying to use Haskell. Had to suffer through it for my first quarter of intro to CS and was only too glad to move on.
peq 13y ago
I think most Unix commands have a function type which is not representable in haskell, if you don't want to fall back to strings everywhere. So you end up with many functions like ls and ls'. For a shell I prefer a dynamically typed language.
- joeyh 13y ago
  Typeclasses to the rescue.. ls :: LsOptions -> IO Listing instance ToString Listing where ... instance Default LsOptions where def = LsOptions [] Now a single `ls` function can yield regular textual output, or the more specific Listing type can be used if you want to say, map over the files listed. toString <$> ls def map toUpper . filesListed <$> ls def The repl can automate the application of toString of course, so the user can just enter `ls def`. Someone better at this than I could probably find a way to make the def parameter be optional, too.
mtdewcmu 13y ago
It looks more usable than scsh, and I like the name.

117 points by tikhonj 13y ago

st0neage 13y ago

Hell? This could be heaven! For everyone.

CraigJPerry 13y ago
>> ls *.* Vs. >> fmap (filter (isInfixOf ".")) ls' No sale!
- st0neage 13y ago
  Actually that was meant to be a joke. Is that really a reason to downvote?
  - adamtulinius 13y ago
    Yes, this isn't reddit.
    - andrewflnr 13y ago
      Truly clever, relevant humor is perfectly acceptable. It's the cheap stuff that deserves to be downvoted. The post in question is, AFAICT, only guilty of making a relevant point in a slightly humorous manner.
- chrisdone 13y ago
  Completely fair criticism. Obviously, I don't mean to continue writing such lengthy code on the command-line, but in order to feel out what's good enough, I need the shell. The brevity can come later. E.g. there's no reason ls "*.*" couldn't be defined, e.g. ls = run . ("ls " ++)
  - saidajigumi 13y ago
    I'd argue that even the double-quotes in `ls "."` are too much for normal usage. There have been many attempts at creating non POSIX-y shells based on various languages, but AFAICT it's a non-starter to require special syntax when running basic command lines. I'm mostly not writing shell scripts, I'm using a command line to interact with the system. As such, I want no barrier to running programs yet a lightweight way to leverage a "real" programming language. Redefining tools like `ls` seems like a red herring as well. I'm not against built-ins (they're necessary), but the Unix toolchain isn't going anywhere anytime soon. You'll still need to pull data out of git, logfiles, munch that data with external tools, etc. As such it's worth thinking about how to best bridge these worlds. If the shell environment can provide a better ls, that's fine, but I suspect it's a design bug if it feels like it needs the built-in for day-to-day usage. On "feel", it also feels like there should be a seamless syntactic protocol for post-POSIX shells, but I've yet to nail down how it would work. Straw-man requirements: - Absolutely no special syntax to run programs - Low-drama way to write "real code", i.e. native scripting language syntax. - Great integration via syntax, shell built-ins for working in Unix-y pipeline. - Replace powerful yet bizarre bash/zsh parameter constructs with better native language tools. By low-drama, think of the success of Markdown vs. HTML, TeX, etc. for markup. Not as powerful, but much easier to use for its use cases. IMO, this is the most powerful thing about the POSIX shells -- there's zero ceremony around running programs and dealing with I/O redirection. That's also the compromise, as things like quoting semantics get hairy. One way a post-POSIX shell could go is to retain this seamlessness while adding a touch more modality so that the worst problems of POSIX shells are eliminated. For example, multiple-quoting or re-quoting should never be needed, real data structures are both available and the default, etc. Anyhow, Hell looks like a fun experiment and sandbox. Enjoy!
    - hyperpape 13y ago
      I agree completely. I've been thinking about this a lot, and non-quoted strings strike me as an absolute requirement for anything that aims to replace the bourne shell and its descendants (as opposed to complementing them in the way that Perl/Python/Ruby do it). But obviously it's hard to have non quoted strings in a programming language. I need to play more with TCL (the one non sh-like language I know that does this) but I think even it has some very strange features that grow out of treating ordinary text as strings.

miga 13y ago

It is not a real shell, since it misses basic pipes. It is just a library for renaming system functions to their Bash-like names... Move on, and look at these: * http://hackage.haskell.org/package/Shellac http://hackage.haskell.org/package/Shellac * http://hackage.haskell.org/package/pipes-shell http://hackage.haskell.org/package/pipes-shell * http://hackage.haskell.org/package/HSH http://hackage.haskell.org/package/HSH * http://hackage.haskell.org/package/shellish http://hackage.haskell.org/package/shellish

rtpg 13y ago
I'm not sure of the types of the functions, but Haskell's arrow typeclass could do arrows in theory.
lelf 13y ago
> since it misses basic pipes To be fair, you don't actually need them lelf:~/srcs/hell$ reverse <$> pwd "lleh/scrs/flel/sresU/" But yes, right now it's just a bunch of renames.
klrr 13y ago
Might note this was "whipped this up in a few hours". I suspect this is just an experiment. But I think this might evolve into something serious, lots of interest was expressed in /r/haskell. On a serious side note, it doesn't need pipes since the shell utilities are wrapped as function which are composable in Haskell.
gregwebs 13y ago
The last 3 links are to shell-scripting libraries, which have a different goal than creating an interactive shell. I would recommend shelly, the library I created: https://hackage.haskell.org/package/shelly https://hackage.haskell.org/package/shelly
maaku 13y ago
Wouldn't pipes be implemented as monads (arrows)? I think it'd be defeating the point to bolt on a Bourne shell convention for Haskell shell, when there's a native capability to be used...
13y ago

marcosdumay 13y ago

A shell made in a pure functional language... It does not look apealing (the main use of a shell is to create side effects), but I'll sure try it.

DanWaterworth 13y ago
The main use of Haskell is to create side effects. It just does so in a principled, constrained manner.
Hemospectrum 13y ago
There's a misunderstanding at work here about how Haskell actually regards side effects. In a few words: It provides an API for declaring side effects, and forces you to use this API when chaining them together, but it does not refuse to acknowledge their existence. Haskell's reputation exaggerates how this API was less powerful, or missing altogether, in early versions of the language. But its reputation is not what you write programs in.
- marcosdumay 13y ago
  No misunderstanding. I know Haskell, and I do like it. But monads (each one) are better constrained to a small part of your code, otherwise you negate all the power you gain by declaring the side effects. And the entire point of a shell is to do IO all over the place.
Sirenos 13y ago
sigh Functional languages are all about keeping side effects under control so that you can tell what will and what will not change the state of the system. Think of it as incorporating awareness of program state into the type-system of the language.
deckiedan 13y ago
As others have replied to you, I think you misunderstand what side effects & IO are. Imagine a "normal" shell type chain: ps -ef | grep 'elephant' | sort -nk2 >> logfile.txt neither `grep`, nor `sort` should have any side effects, and if they do, then you have potential for weird bugs later on. (imagine your / is mounted read only, and sort has a side effect of writing everything to a temp file. now suddenly this otherwise sane looking chain stops working). In the command, you have a single input, and a single output (which has a specific mode, append). Those are the only IO functions which you've specified, but you have no guarantee that anything else will not make a mess of things. The dream for "pure functional" shell scripting would be where the side effects are more obvious, and controllable, not to eliminate them.

sur 13y ago

There's also scsh, which uses Scheme: http://www.scsh.net/ http://www.scsh.net/

klibertp 13y ago
Unfortunately, on FreeBSD: ===> scsh-0.6.7 is marked as broken: fails to install on amd64. And I really wanted to play with it. Seems like I will have to help in Scsh reimplementation in Racket before I can do this.
jfb 13y ago
It's not much of an interactive shell, although it's perfectly cromulent for writing shell scripts.

eternalban 13y ago

See: http://www.haskell.org/haskellwiki/Simple_Unix_tools http://www.haskell.org/haskellwiki/Simple_Unix_tools & http://www.haskell.org/ghc/docs/7.6.2/html/libraries/base-4.6.0.1/src/System-Console-GetOpt.html http://www.haskell.org/ghc/docs/7.6.2/html/libraries/base-4.... ps: Haskell is such a Gloriously Happy Land, why make it "hell"?

chrisdone 13y ago
Read the page?
- eternalban 13y ago
  "Irony" is a side effect. Haskell is pure .. :P
ChickeNES 13y ago
I feel like "hell" is a perfect description for trying to use Haskell. Had to suffer through it for my first quarter of intro to CS and was only too glad to move on.

peq 13y ago

I think most Unix commands have a function type which is not representable in haskell, if you don't want to fall back to strings everywhere. So you end up with many functions like ls and ls'. For a shell I prefer a dynamically typed language.

joeyh 13y ago
Typeclasses to the rescue.. ls :: LsOptions -> IO Listing instance ToString Listing where ... instance Default LsOptions where def = LsOptions [] Now a single `ls` function can yield regular textual output, or the more specific Listing type can be used if you want to say, map over the files listed. toString <$> ls def map toUpper . filesListed <$> ls def The repl can automate the application of toString of course, so the user can just enter `ls def`. Someone better at this than I could probably find a way to make the def parameter be optional, too.

mtdewcmu 13y ago

It looks more usable than scsh, and I like the name.