This is certainly an interesting use of Scheme macros for a shell-like DSL. For a long time I've mused over ideas for a Unix-ish shell that embeds first-class access to a richer scripting language than typical shell scripting. In this light, Scsh is similar to many other projects I've seen over the years in various languages, in that its effective aim is more about shell-like scripting in an alternate language.
For my goals where all of these attempts fall down, including Scsh, is in the syntax. One of the best aspects of working in the various Unix shells is their very low syntactic ceremony. I find that even similar "shell nouveau" attempts in Ruby are cumbersome, despite that language having relatively low syntactic ceremony for a full programming language. E.g. I don't want to have to write even one function/method call just to run a program. That's far too heavyweight for a user shell, even when the least it adds are a pair of parens.
For a new shell that I'd actually want to use, there seem to be two key criteria:
1. There needs to be a radically low-ceremony user interface that respects everything we've learned from Unix shells over the years. Perhaps it's best to think of this UI as its own DSL inspired by a subset of existing shell UI. This includes staples such as pipeline composability, etc. Ironically, the best new-generation examples of this principle seem to be GUI launcher tools like Quicksilver and its conceptual offspring. While far from being Unix shells, they can be seen as a wonderful generalization/simplification of the essential shell "<thing> <modifiers>" + completion UI.
2. A seamless way to enter "write real code" mode, where the focus of "real code" is on shell power-user workflows and customizing and extending shell functionality. I'm not interested in making this into yet another standalone scripting tool, since there are a plethora of choices for modern languages that cover this ground. E.g. if one uses a shell backed by a mature language such as Scheme/Ruby/Python/etc. then the normal runtimes for those languages can support standalone scripting use. As needed, useful idioms developed in the shell environment could easily be exported as a library for use in standalone scripts. (And again, I think Scsh's shell-like macros are a great example of that.)
"sh" [1] by amoffat did something similar to this in python. It's so marvelous I've also ported the same ideas to "gosh" [2] for use in golang and "josh" [3] for use in java. There's probably others as well -- I'd love to hear about more options in other languages.
(The golang implementation is probably my favorite of these, since pipelining the output is by far the most pleasant experience there, and channels actually provide parallelism in a similar way what one expects from unix pipes. I'll admit I haven't benchmarked, but I suspect pipelining a lot of information in the python one is going to encounter the GIL; and as for the java one, well, let's just say I'd like to have a word with the authors of the current java subprocess invocation APIs.)
The grandaddy of all of those is probably the http://perldoc.perl.org/Shell.html module in Perl. The idea is really nice for a lot small scripts but can seem to hide some magic because you're treating commands as functions.
I love sexprs. In fact, I generally prefer prefix notation with the extra parens. However, for such a high frequency interactive use case, it really does meet the cost/benefit requirements to have specialized syntax...
I'm quite familiar with Scheme and can do useful things with it. Not so sure how comfortable it would be to have Scheme on the command line.
Maybe it's just a matter of getting used to s-expr in that context, but after a few decades learning the classic command-line syntax, making that change could be hard.
OTOH the ability to use low level OS functions at the shell prompt or in a script might compensate for the trouble. Giving it a try would be the only way to find out. I might just do that and see what happens.
The documentation seems to suggest it supports through a library a "rec" as in recursive command as documented here http://srfi.schemers.org/srfi-31/srfi-31.html ... not sure how to extrapolate that to your specific example however :D
Nah, it shouldn't be hard once you're used to (fun a b) syntax. So what would be pipe(cmd1(), cmd2()) in an algolic syntax is instead (pipe (cmd1) (cmd2)) and so on from there.
[+] [-] saidajigumi|11 years ago|reply
For my goals where all of these attempts fall down, including Scsh, is in the syntax. One of the best aspects of working in the various Unix shells is their very low syntactic ceremony. I find that even similar "shell nouveau" attempts in Ruby are cumbersome, despite that language having relatively low syntactic ceremony for a full programming language. E.g. I don't want to have to write even one function/method call just to run a program. That's far too heavyweight for a user shell, even when the least it adds are a pair of parens.
For a new shell that I'd actually want to use, there seem to be two key criteria:
1. There needs to be a radically low-ceremony user interface that respects everything we've learned from Unix shells over the years. Perhaps it's best to think of this UI as its own DSL inspired by a subset of existing shell UI. This includes staples such as pipeline composability, etc. Ironically, the best new-generation examples of this principle seem to be GUI launcher tools like Quicksilver and its conceptual offspring. While far from being Unix shells, they can be seen as a wonderful generalization/simplification of the essential shell "<thing> <modifiers>" + completion UI.
2. A seamless way to enter "write real code" mode, where the focus of "real code" is on shell power-user workflows and customizing and extending shell functionality. I'm not interested in making this into yet another standalone scripting tool, since there are a plethora of choices for modern languages that cover this ground. E.g. if one uses a shell backed by a mature language such as Scheme/Ruby/Python/etc. then the normal runtimes for those languages can support standalone scripting use. As needed, useful idioms developed in the shell environment could easily be exported as a library for use in standalone scripts. (And again, I think Scsh's shell-like macros are a great example of that.)
[+] [-] readstoomuch|11 years ago|reply
[+] [-] latiera|11 years ago|reply
[+] [-] heavenlyhash|11 years ago|reply
[1] https://github.com/amoffat/sh/
[2] https://github.com/polydawn/pogo/blob/master/gosh-demo.go
[3] https://github.com/polydawn/josh/
(The golang implementation is probably my favorite of these, since pipelining the output is by far the most pleasant experience there, and channels actually provide parallelism in a similar way what one expects from unix pipes. I'll admit I haven't benchmarked, but I suspect pipelining a lot of information in the python one is going to encounter the GIL; and as for the java one, well, let's just say I'd like to have a word with the authors of the current java subprocess invocation APIs.)
[+] [-] simcop2387|11 years ago|reply
[+] [-] jeremycw|11 years ago|reply
[1] https://github.com/arturadib/shelljs
[+] [-] saidajigumi|11 years ago|reply
[+] [-] brandonbloom|11 years ago|reply
[+] [-] jrapdx3|11 years ago|reply
Maybe it's just a matter of getting used to s-expr in that context, but after a few decades learning the classic command-line syntax, making that change could be hard.
OTOH the ability to use low level OS functions at the shell prompt or in a script might compensate for the trouble. Giving it a try would be the only way to find out. I might just do that and see what happens.
[+] [-] simcop2387|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] th0ma5|11 years ago|reply
[+] [-] rml|11 years ago|reply
[+] [-] rml|11 years ago|reply
* Geiser integration that (mostly!) works: https://github.com/rmloveland/geiser-scsh
* The manual in Texinfo format: https://github.com/rmloveland/scsh-manual-texinfo
[+] [-] antocv|11 years ago|reply
[+] [-] leoc|11 years ago|reply