Live data from Hacker News

Use Haskell for shell scripting

haskellforall.com

51–60 of 105 posts

Re: Use Haskell for shell scripting

#51

Earlier quoted context omitted.

If your arguments aren't exclusive, you can pass a list of algebraic data. If they are exclusive, you can construct a type for them.

> If your arguments aren't exclusive, you can pass a list of algebraic data. Which you need to prefix to avoid clashes. > If they are exclusive, you can construct a type for them. Which is going to end up being a record, which: - is awkward to build (compared to just giving options to a command or arguments to a function) - will most likely need to be an instance of Default - which needs to have its fields prefixed t…

> prefixes, default instances

Also bad setters ("record {field = val}" looks nice but useless, as not a function).

I hope the developers of GHC also clearly see the problem and someday will be engaged in it. Then the language becomes much more expressive.

Is that task exists somewhere in roadmap?

Re: Use Haskell for shell scripting

#52
After learning Perl I started using it where some more educated people might recommend a proper shell script. My thinking is that using what you know is a whole lot more efficient than learning a new tool for a small job, even if some people think it is the right tool. I am sure it is no different for people familiar with Haskell.

Re: Use Haskell for shell scripting

#53
post #14

I don't know much about Haskell, but I thought it had some properties to isolate side effects, but the code he gives: main = do cd "/tmp" mkdir "test" output "test/foo" "Hello, world!" -- Write "Hello, world!" to "test/foo" stdout (input "test/foo") -- Stream "test/foo" to stdout rm "test/foo" rmdir "test" sleep 1 die "Urk!" Clearly doesn't (it creates a directory, writes in a file, removes that file and that directo…

Haskell does not force you to indicate that a function has possible side effects in the program source code, the type of the function will however have such an indication. Here main has type IO (), and the IO indicates it can do arbitrary I/O and mutation. Haskell will infer the type for you so you don't need to declare it in the source code.

So I disagree with the claim "without anything indicated by the function main", and would amend to "without anything indicated explicitly by the source code, leaving the only indication in the inferred type".

Re: Use Haskell for shell scripting

#54

After learning Perl I started using it where some more educated people might recommend a proper shell script. My thinking is that using what you know is a whole lot more efficient than learning a new tool for a small job, even if some people think it is the right tool. I am sure it is no different for people familiar with Haskell.

Agreed. I look upon people who use PHP for shell scripting with a sigh and a shaken head, but I can't fault them for it. PHP works, PHP is quick to write, and for many tasks, PHP is sufficient.

I hope Haskel can gain traction in this area, if only because options are always nice to have, and competition forces everyone to bring their best game.

Re: Use Haskell for shell scripting

#55
post #33
post #29

Earlier quoted context omitted.

I agree about the benefits of isolating side effects and IO - I generally code in python, and my code tends to look like: def main_function(args): data = get_data(args) result = do_calculations(data) push_results(result, args) Where the function do_calculations is somewhat pure - no side effects, but I do use local variables that I modify inside the function. > You are right. In this case effects are not isolated. Bu…

You're right that Haskell doesn't distinguish different IO actions other than by the type they return. There are certainly libraries that do this though, although they aren't widely used. Even though Haskell doesn't distinguish different classes of IO actions, it still distinguishes IO actions from other kinds of actions (such as stateful actions as per your example), and pure computations and that provides a hell of…

> Not widely used...

I use them in every single application I write, or I make my own tighter, more specific ones. They're incredibly useful in real world apps.

Re: Use Haskell for shell scripting

#58

After learning Perl I started using it where some more educated people might recommend a proper shell script. My thinking is that using what you know is a whole lot more efficient than learning a new tool for a small job, even if some people think it is the right tool. I am sure it is no different for people familiar with Haskell.

I do a lot of shell scripting, and I'm not sure there is such a thing as a "proper" shell script. The shell just isn't a great programming language. Just about any modern scripting language is better, starting with Perl. But the shell has been the lingua franca of the Unix world for decades now. It's the one language that you can pretty much guarantee is on any Unix or Linux server, even pretty ancient ones.

I don't doubt that Haskell isn't a better scripting language language than the shell, but you can't assume /usr/bin/env runhaskell is going to return anything on random Linux servers. Perl and Python, maybe, but Haskell isn't there yet.

Re: Use Haskell for shell scripting

#59
post #32

Earlier quoted context omitted.

I saw those as regular parser that returns text but not just grep wrapper. Yes It has function named 'grep', but its not grep wrapper. It looks like `lstree` could be combined with `grep` function for emulate `grep -r`.

Take lstree then. How would you give it an option giving the kind of ordering you want?

I guess you wouldn't, you'd have a sort function afterwards.

...for Unix' insistence on composability, the shell tools are often unnecessarily monolithic, probably because that's the only sane way if the only type you have in interconnect is `string`.

Re: Use Haskell for shell scripting

#60

Earlier quoted context omitted.

If your arguments aren't exclusive, you can pass a list of algebraic data. If they are exclusive, you can construct a type for them.

> If your arguments aren't exclusive, you can pass a list of algebraic data. Which you need to prefix to avoid clashes. > If they are exclusive, you can construct a type for them. Which is going to end up being a record, which: - is awkward to build (compared to just giving options to a command or arguments to a function) - will most likely need to be an instance of Default - which needs to have its fields prefixed t…

Prefixes are a problem, no arguing about that. But...

> is awkward to build (compared to just giving options to a command or arguments to a function)

Idiomatic bash: apt-get install package_name

Idiomátic haskell: apt_get $ AptInstall package_name

What is so awkward about that?

Post reply on HN