Hell: A Haskell Shell

by tikhonj • 13 years ago

117 37 13 years ago

st0neage2• 13 years ago

Hell? This could be heaven! For everyone.

    >> ls *.*

Vs.

    >> fmap (filter (isInfixOf ".")) ls'

No sale!

st0neage2• 13 years ago

Actually that was meant to be a joke. Is that really a reason to downvote?

chrisdone2• 13 years 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 " ++)

miga• 13 years 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/pipes-shell

* http://hackage.haskell.org/package/HSH

* http://hackage.haskell.org/package/shellish

rtpg• 13 years ago

I'm not sure of the types of the functions, but Haskell's arrow typeclass could do arrows in theory.

lelf• 13 years 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.

klrr2• 13 years 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• 13 years 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

maaku• 13 years 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...

asdasf• 13 years ago

How does something this bad end up the top comment? Three out of four links you provided are completely irrelevant. It is not missing pipes. Pipes are a simple composition operator. Haskell already has that, no need to make a special version for this.

klrr2• 13 years ago

While it's true that you can't really pipe programs conveniently yet it sure supports composition with all functions as you suggest. Just wanted to note in case that was what the comment above was thinking about. Except that I pretty much agree with you, current top comment is crap.

AsymetricCom• 13 years ago

Otherwise the syntax would live up to the shell's name.

marcosdumay2• 13 years 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• 13 years ago

The main use of Haskell is to create side effects. It just does so in a principled, constrained manner.

Hemospectrum• 13 years 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.

marcosdumay2• 13 years 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• 13 years 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• 13 years 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.

joeyh2• 13 years ago

Sort does have the side effect of writing to a temp file, when the input to be sorted is large. :)

yongjik• 13 years ago

Except that usually grep and sort can read files, or entire directories, which is considered a "side effect" in Haskell.

(Not to mention checking locales to decide how to sort, checking if the output is terminal so that we can add colors, but only if the environment variable says so, and on, and on...)

IsTom• 13 years ago

You can write C in Haskell (I do sometimes, for SPOJ or something) if you really want. However, Haskell lets you say that something has no side effects, which is very useful for reasoning about programs.

freyrs3• 13 years ago

And almost all Haskell programs do perform side-effects, they just demarcate the sections of their logic that do and don't have effects.

The meme that Haskell can't do side-effects or that's its hard just won't die...

sur• 13 years ago

There's also scsh, which uses Scheme:

http://www.scsh.net/

klibertp• 13 years 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• 13 years ago

It's not much of an interactive shell, although it's perfectly cromulent for writing shell scripts.

eternalban2• 13 years ago

See: http://www.haskell.org/haskellwiki/Simple_Unix_tools & 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"?

chrisdone2• 13 years ago

Read the page?

eternalban2• 13 years ago

"Irony" is a side effect. Haskell is pure .. :P

ChickeNES• 13 years 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• 13 years 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.

joeyh2• 13 years 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• 13 years ago

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

Hell: A Haskell Shell

Related Stories