[Haskell-cafe] Re: develop new Haskell shell?

[Brian Hulley]

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.