
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
Well someone had to define the meaning of basename so if we make the definition of renif similarly built-in the comparison is between
ls >>= mapM_ (renif "txt" "hs")
and
for a in *.txt; do mv $a $(basename $a .txt); done
This comparison is unfair because basename is a much more generic operation than renif. The Haskell code should be something like
glob "*.txt" >>= mapM_ (\a -> mv a (basename a ".txt" ++ ".hs")) [rearranged] On the other hand, I'm entirely in favor of extending Haskell with functions like glob :: String -> IO [String]. That would be useful.
Why assume all filenames are strings? Is it not better to make a distinction between a file and a directory? Why fix everything down to the IO monad? In any case, the Haskell above is still just as short as the UNIX command.
So the Haskell command is shorter, easier to read, and more re-usable, because mapM_ (renif "txt" "hs") can be used anywhere that supplies a list of files whereas "for a in *.txt" doesn't make the source of the list explicit. Do they come from the current directory? What if some other list of files should be used?
This makes no sense. Bash has its own set of rules.
But who wants to waste their life learning them? :-)
The for statement iterates over a list, which in this case is generated by a glob. If you want something else, you use the appropriate construct. The body of the for loop is just as reusable as the corresponding Haskell code.
Ok perhaps I was being a little bit unfair. ;-)
My reaction to this thread is the same as Donn Cave's: even after reading through the whole thread, I don't understand what a Haskell shell is supposed to be. It feels like people are more interested in capturing territory for Haskell than in solving any actual problem. For simple commands and pipes, the bash syntax is perfect.
But it's surely just an accident of historical development. Now that we've got Haskell, why bother with old crusty stuff that's awkward and idiosyncratic?
For anything nontrivial, I use some other language anyway.
Why not always just use Haskell?
A Haskell shell is never going to be ubiquitous
At this rate it's never even going to get a chance...
, and Haskell syntax is inferior to bash syntax for 99% of the command lines I type.
Well perhaps this is just a matter of personal preference. Certainly it's good that everyone can use whatever they prefer. I personally disagree that Haskell syntax is inferior, except perhaps for the need to use quotes but that is imho a very minor distraction. Much more important is that by using the same language for shell + program development, whatever that language is, people could concentrate on solving problems instead of having to continually adapt themselves to the different mindsets of the different communities which develop various modes of interaction with a computer. Regards, Brian.