[Haskell-cafe] Re: develop new Haskell shell?
On 2006-05-12, Jeremy Shaw [EMAIL PROTECTED] wrote: At Thu, 11 May 2006 23:05:14 +0100, Brian Hulley wrote: Of course the above could no doubt be improved but surely it is already far easier to understand and much more powerful than the idiosyncratic text based approach used in UNIX shells (including rc). The idea of representing unix pipes as monads has been around for a while -- but what most people fail to account for is that many (most?) real-world shell scripts also need to deal with return values and stderr. Even standard unix shells are pretty terrible in this regard -- so if we could do it *better* than standard shells -- that could be pretty compelling. Here are some simple examples of things to handle, starting with failures in a pipeline: $ aoeu | cat -n ; echo $? bash: aoeu: command not found 0 $ Sweet! A successful return code even though there is clearly a failure. Bash 3.x *finally* added, set -o pipefail -- which would cause the above to return an error. Unfortunately, there is no way to tell which part of the pipeline failed, or any way to attempt recovery of the part that failed. See also the pipestatus/PIPESTATUS arrays in e.g. zsh and ksh. Maybe it's in bash too these days. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: develop new Haskell shell?
On 2006-05-12, Max Vasin [EMAIL PROTECTED] wrote: Brian == Brian Hulley [EMAIL PROTECTED] writes: Brian Some other possibilities are: Brian 1) Every command returns a pair consisting of result and return Brian code IMHO the distinction between command's output (to stdout and stderr) and its return code is one of the faults in UNIX shells. Nothing, but log should be written to stdout by command, and stderr should be useless if we use exceptions (I'm not quite sure). You have failed to grasp the problem domain and the composability provided. Requiring names for output is worse than requiring names for functions. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: develop new Haskell shell?
Brian == Brian Hulley [EMAIL PROTECTED] writes: Brian Some other possibilities are: Brian 1) Every command returns a pair consisting of result and return Brian code IMHO the distinction between command's output (to stdout and stderr) and its return code is one of the faults in UNIX shells. Nothing, but log should be written to stdout by command, and stderr should be useless if we use exceptions (I'm not quite sure). Brian 2) Use exceptions instead of stderr instead of stderr and return code. The return code of `test' is in fact its result. Brian 3) Use a more complicated monad It may still be a good idea to take the top 20 unix utils and code them as native haskell functions and see how far that goes. I know there are some existing libraries that deal with basic stuff like mv, etc. Has anyone implemented grep, find, etc? Brian This is also how I would start because it would allow all the Brian control flow/ ease of use issues to be explored just using GHCi Brian / Hugs etc before tackling the problem of how to get binaries Brian to interface with the shell. -- WBR, Max Vasin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: develop new Haskell shell?
Brian Hulley wrote: Donn Cave wrote: (cd /etc/stuff; cat * result) Well the problem here is that the command leaves you in /etc/stuff so you have to remember this when you subsequently execute another command. No it doesn't. The parentheses around the command sequence cause it to run in a subshell with its own private working directory. 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)) 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. 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. 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. For anything nontrivial, I use some other language anyway. I long ago wrote a Perl script to do a far more general form of the renaming example you gave above. As far as I know, the only reason people write nontrivial /bin/sh scripts is that it's the only scripting language that's universally available on Unix systems. Even Perl isn't deployed everywhere. A Haskell shell is never going to be ubiquitous, and Haskell syntax is inferior to bash syntax for 99% of the command lines I type. On the other hand, I'm entirely in favor of extending Haskell with functions like glob :: String - IO [String]. That would be useful. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
On Fri, 12 May 2006, Ben Rudiak-Gould wrote: ... For simple commands and pipes, the bash syntax is perfect. For anything nontrivial, I use some other language anyway. I long ago wrote a Perl script to do a far more general form of the renaming example you gave above. As far as I know, the only reason people write nontrivial /bin/sh scripts is that it's the only scripting language that's universally available on Unix systems. I have a blind spot here due to a visceral dislike of Perl, but I do think there's a slim chance that a really well designed language could be useful in that niche - roughly speaking, non-trivial shell scripts. You're right, I wouldn't be able to use it at work, just like rc or, for that matter, Haskell, but still I'd love to see it happen. I just think really well designed is a tall order, and the notion that you can get there by just dropping Haskell into this application domain is an absurdity on the order of Edgar Rice Burroughs' fantasy of Tarzan appearing out of the jungle and being appointed chief of the Waziri. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Ben Rudiak-Gould wrote: 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. I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. On the other hand, as soon as a script has at least some programming logic in it, bash (or anything similar) soon becomes a huge PITA. Just think of all the different quotes and how difficult it is to write a script that doesn't go bonkers if it encounters a filename with a space in it (or a parenthesis, a bracket, an asterisk or anything of a myriad special chars I forgot). Haskell shines here; in a combinator library no quoting is necessary and the typechecker will detect most blunders in the equivalent code. Besides, Cabal could benefit from a good file manipulation library, as could a lot of other programs. I long ago wrote a Perl script to do a far more general form of the renaming example you gave above. So did I, but I don't want to experience that ever again. Anyway, for complex renaming, there's always mmv. On the other hand, I'm entirely in favor of extending Haskell with functions like glob :: String - IO [String]. That would be useful. Yes, of course. More specific types would be a good thing, though. Representing both file names and globs by strings will soon reproduce the mess of quote chars that makes sh such a bad programming language. Udo. -- It is explained that all relationships require a little give and take. This is untrue. Any partnership demands that we give and give and give and at the last, as we flop into our graves exhausted, we are told that we didn't give enough. -- Quentin Crisp, How to Become a Virgin signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Udo Stenzel wrote: I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. This seems to be your only objection. It might be solvable by making some rule that an identifier that's used in a value position would be automatically bound to a function/value found by instantiating to a binary in the file system if it's not already bound, and there would need to be some rules about how binaries would work to cooperate with the Haskell type system. Another approach, to allow GHCi to be used as a shell immediately (given the right module with useful commands like ls, cat etc which could be written right now) would be to just have a shorter name for system eg what about: % #foo Just think: three extra characters but an infinity of new possibilities. :-) Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
On Fri, 12 May 2006, Brian Hulley wrote: Udo Stenzel wrote: I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. This seems to be your only objection. It might be solvable by making some rule that an identifier that's used in a value position would be automatically bound to a function/value found by instantiating to a binary in the file system if it's not already bound, and there would need to be some rules about how binaries would work to cooperate with the Haskell type system. What about the parameters - certainly there's little point in relieving me of the bother of quoting a command name, if I have to quote each parameter? Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Donn Cave wrote:
On Fri, 12 May 2006, Brian Hulley wrote:
Udo Stenzel wrote:
I'd like one as a scripting environment, a bit like scsh, just
strongly typed and easier on the eyes. Haskell as interactive
shell would be a nightmare indeed, having to type 'system foo'
instead of simply 'foo' for everyday commands just won't cut it.
This seems to be your only objection. It might be solvable by making
some rule that an identifier that's used in a value position would be
automatically bound to a function/value found by instantiating to a
binary in the file system if it's not already bound, and there would
need to be some rules about how binaries would work to cooperate
with the Haskell type system.
What about the parameters - certainly there's little point in
relieving me of the bother of quoting a command name, if I have to
quote each parameter?
My idea of a Haskell shell would be that everything in the computer would be
visible as a strongly typed monadic value, so for example, instead of typing
$ ghc -c -O1 Main.hs
ghc would appear in the shell as if it was a normal Haskell function with
this type:
ghc :: GHCOptions - [FileName] - Shell ()
where GHCOptions would be a record. For each binary, there would be default
options, so from Haskell you could type:
Shell ghc ghcDefaultOptions{link=False, opt=1} [Main.hs]
It might even be possible to make a syntactic extension to Haskell that any
function whose first argument is a record could be called with the record
brackets immediately after the function name, (ie with an implicit default
record based on the name of the function before the opening brace) so the
above could be written as:
Shell ghc{link=False, opt=1} [Main.hs]
There would have to be some specification somewhere to tell the binder what
the type of the binary (and its options) was etc.
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: develop new Haskell shell?
Brian Hulley [EMAIL PROTECTED] writes: Donn Cave wrote: On Fri, 12 May 2006, Brian Hulley wrote: Udo Stenzel wrote: I'd like one as a scripting environment, a bit like scsh, just strongly typed and easier on the eyes. Haskell as interactive shell would be a nightmare indeed, having to type 'system foo' instead of simply 'foo' for everyday commands just won't cut it. This seems to be your only objection. It might be solvable by making some rule that an identifier that's used in a value position would be automatically bound to a function/value found by instantiating to a binary in the file system if it's not already bound, and there would need to be some rules about how binaries would work to cooperate with the Haskell type system. What about the parameters - certainly there's little point in relieving me of the bother of quoting a command name, if I have to quote each parameter? My idea of a Haskell shell would be that everything in the computer would be visible as a strongly typed monadic value, so for example, instead of typing $ ghc -c -O1 Main.hs ghc would appear in the shell as if it was a normal Haskell function with this type: ghc :: GHCOptions - [FileName] - Shell () I and a fellow student have implemented something along those lines. We walk through the $PATH and write a small stub definition for each program. This is then compiled and loaded using hs-plugins. The result is that you can access for example ghc from the command line. The type of the automatically generated functions are e.g.: cat :: Program String String which is the best type you can give without a lot of manual labour (it really ought to be [Word8]). You can then combine programs (and standard haskell functions) like so: cat | map toUpper where (|) :: (Cmd c1, Cmd c2, Marshal t, Marshal i, Marshal o) = c1 i t - c2 t o - Command i o and instance Cmd Program ... instance Cmd (-) .. So the interface is not monadic but more similar to arrow composition. This is probably a bad idea since you need to use something like xargs to run a command on each item in the input. As others (Donn) have pointed out, having to write (in our syntax) e.g. ssh -.l #jansborg #remote.mdstud.chalmers.se gets old really quickly for interactive use, so I don't think a haskell shell is really useful other than for scripting. Basic job control and tab completion for programs and files (but not normal haskell bindings) is implemented. The code is available here: http://www.mdstud.chalmers.se/~jansborg/haskal.tar.gz but please note that it is not at all finished, likely quite buggy, completely undocumented and not really well thought through. /Mats ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
