Show HN: Forsh – A Unix shell embedded in Forth(bitbucket.org) |
Show HN: Forsh – A Unix shell embedded in Forth(bitbucket.org) |
1) I made Unix commands a first-class variable type. You could create a single Unix command and store it into a variable. You could also set up several commands as a pipe, and save that into a variable.
2) redirection and pipes are more Forth in style. Much like adding two values:
2 3 +
cmd1 cmd2 |
cmd1 "filename" |
It was a fun project to write (it even included history!) but as a practical shell? Not so much. The syntax left much to be desired for an interactive shell.
[1] Unix systems programming. The class project was a Unix shell. I had, by that time, already written a Forth-like programming language on my own [2], which meant I could do the advanced shell (programmable) instead of the simple shell (command execution and redirection only).
[2] I was seriously interested in Forth at the time.
There is nothing stopping Forsh from being used that way. The convenience words from the README use a global variable to tell them where to build commands and overwrite the memory for every new command because the common case is that you as a user don't really care much about having arbitrary history (In any case, gforth already uses readline, so I get history for free). The words underneath all take that location as an argument on the stack. You could write some words that allocate space for each new command without changing the underlying libraries.
The key to thinking about pipe words in Forsh is that they execute a given command and consume and/or leave a file pointer to a command's stdout on the stack. This is why there are multiple pipe words. They have different stack effects.
`>|` (begin pipeline) only leaves a file pointer. `|` (continue pipeline) consumes and leaves a file pointer. `|>` (end pipeline) only consumes a file pointer.
This allows the pipe words to interoperate with any file I/O words in gforth.
If you want to "save a command to a variable", you just use a regular Forth word. [bracket] words make things work in compile mode.
`: hack [c] echo [p] hack! $ ;`
Executing hack will then build and execute the command. This also works with arbitrary pipeline fragments.
I did my best with syntax, but existing shells have already aggressively minimized typing for short commands. The most I could do was have people type `l ` instead of `--` for long options and `s ` instead of `-` for short options. However, I find quoting much improved over existing shells. You specify the quote character when you type the command, so there is no escaping. You just pick a character that doesn't exist in the string. You are ok as long as your string does not included every printable ASCII character.
Shell Has a Forth-like Quality
I could write versions that worked on 32-bit, but I don't have a 32-bit machine to test on.
Concatenative programming exposes you to a new style of thinking—IMO it’s the perfect marriage of imperative and functional programming, because you can reason about your code either way: as a “pipeline” composition of functions, or as a sequence of imperative operations on the data stack. In terms of PL theory they have a bunch of elegant algebraic properties too.
What Forth is best at is boostrapping from bare metal to a reasonably high level language with the simplest design possible. Forth was first written at a time when there was a staggering amount of hardware in existence, so reimplementing the base language as quickly as possible was a huge plus. It's got a low floor but a high ceiling. It is a free-wheeling language that allows both very clever and very stupid things.
Unfortunately, this legacy means lots of fragmentation. There is not one cohesive community or set of standard libraries. Forth is very much a "do it yourself" language.
Forth can be very concise because all parameters are passed implicitly on the data stack by default. Parameters and arguments lead to a lot of duplication of expression in traditional languages because you need to give them explicit names both inside and outside the function.
If you prefer, it helps to treat it as a functional language where all functions take a stack and return a stack. All programs are a space separated list of function names. Of course, nothing stops you from using all the global variables you want.
One thing that's nice about the language is that it's the simplest language you can implement on your own without going insane!
I've written a couple of intepreters for the language, in Perl, in C, and used it on cheap ESP8266 chips, but its something that's more of a fun diversion than a practical/useful thing for me.
So in short "Yes, it is fun", but I'm not so sold on it being "useful", except that learning new things is almost never a mistake.
You make that sound like it's a BAD thing...
It seems to be useful & stable enough for real work, although I have an ulterior motive as well. I work on Kitten, a statically typed concatenative language (Factor : Smalltalk/Lisp :: Kitten : OCaml/C), and I’m hoping to (finally) get out an initial release soon. So I have an incentive to tell people to use Factor, to get more people interested in the paradigm so they go seeking other offerings if they find it interesting/useful but Factor isn’t a good fit.
[1]: irc://freenode.net/#concatenative