I did a Forth-like Unix shell in college (mid 90s) as a class project [1]. The differences I see from mine are:
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 +
To create a pipe, you create the two commands and then pipe them:
cmd1 cmd2 |
I'm looking over the code, and I don't think I finished redirection to tell the truth, but I can see it being easy to add it like:
cmd1 "filename" |
since variables are typed in my Forth-like language.
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.
Hello, everyone. I would have responded sooner but I spend most of my workday in a closed network for security reasons (defense contractor), and don't have much internet access over the course of the day.
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.
It’s very fun as low-level languages go. I like gforth[1]. If you want modern high-level languages in the same family, look into “concatenative programming”. In particular, Factor[2] is a cool Smalltalk-like object-oriented concatenative language with a nice interactive environment. It’s still under somewhat active development, but they could really use more users to drive progress.
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.
Is Factor still being maintained? I seem to remember that the 0.97 release came out some years ago, and it's worrisome (in terms of investment of time in learning a new language) to think it might be frozen pre-1.0 release.
Yeah, there’s still a steady trickle of maintenance work by a couple of guys. The latest commits were just a couple weeks ago. It’s just that no one has taken the time to put together an official release lately, and it seems like calling it 1.0 has sorta been “somebody else’s problem” for a while now, partly because the original author is no longer involved. Like I said, I think what they really need is motivated early adopter–type users to provide an incentive to improve it.
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.
There’s also an IRC channel[1] and I’m the mod of a subreddit[2] for people interested in the paradigm. They both have fairly low/intermittent traffic but there’s a small group of dedicated people, some programming in Factor, several (myself included) working on their own languages.
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.
It's fun to learn, and one of the first interpreted environments. What it enables is quick development on platforms with modest resources! Instead of compiling and executing you could develop quickly! Haven't used it for anything more than to do some examples in some tutorial.
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 never found a compelling use for FORTH, but I've loved it since I was first exposed to it. The idea that you can define your own "words", essentially writing your own syntax, is very seductive.
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.
Ah, the joy of telling someone to hold down Command+Alt+O+F while booting just to eject their CD... (weirdly enough the most frequent Open Firmware use case on Macs)
I did a Forth-like Unix shell in college (mid 90s) as a class project [1]. The differences I see from mine are:
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:
To create a pipe, you create the two commands and then pipe them: I'm looking over the code, and I don't think I finished redirection to tell the truth, but I can see it being easy to add it like: since variables are typed in my Forth-like language.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.
Hello, everyone. I would have responded sooner but I spend most of my workday in a closed network for security reasons (defense contractor), and don't have much internet access over the course of the day.
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.
Related :)
Shell Has a Forth-like Quality
http://www.oilshell.org/blog/2017/01/13.html
https://news.ycombinator.com/item?id=13477842
Didn't the old Sun workstations boot into a Forth interpreter?
Was / is Forth good and useful? Bonus; is it fun?
It’s very fun as low-level languages go. I like gforth[1]. If you want modern high-level languages in the same family, look into “concatenative programming”. In particular, Factor[2] is a cool Smalltalk-like object-oriented concatenative language with a nice interactive environment. It’s still under somewhat active development, but they could really use more users to drive progress.
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.
[1]: https://www.gnu.org/software/gforth/
[2]: http://factorcode.org/
Is Factor still being maintained? I seem to remember that the 0.97 release came out some years ago, and it's worrisome (in terms of investment of time in learning a new language) to think it might be frozen pre-1.0 release.
Yeah, there’s still a steady trickle of maintenance work by a couple of guys. The latest commits were just a couple weeks ago. It’s just that no one has taken the time to put together an official release lately, and it seems like calling it 1.0 has sorta been “somebody else’s problem” for a while now, partly because the original author is no longer involved. Like I said, I think what they really need is motivated early adopter–type users to provide an incentive to improve it.
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.
Since you bring up concatenative programming in general, I recently came across https://concatenative.org and think some people here might like it.
There’s also an IRC channel[1] and I’m the mod of a subreddit[2] for people interested in the paradigm. They both have fairly low/intermittent traffic but there’s a small group of dedicated people, some programming in Factor, several (myself included) working on their own languages.
[1]: irc://freenode.net/#concatenative
[2]: https://www.reddit.com/r/concatenative
What are your metrics?
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.
It's fun to learn, and one of the first interpreted environments. What it enables is quick development on platforms with modest resources! Instead of compiling and executing you could develop quickly! Haven't used it for anything more than to do some examples in some tutorial.
One thing that's nice about the language is that it's the simplest language you can implement on your own without going insane!
Thanks for your reply!
> without going insane
You make that sound like it's a BAD thing...
I've never found a compelling use for FORTH, but I've loved it since I was first exposed to it. The idea that you can define your own "words", essentially writing your own syntax, is very seductive.
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.
Yes they did.
As did various offerings from Apple, IBM, and several others, once upon a time: https://en.wikipedia.org/wiki/Open_Firmware
Ah, the joy of telling someone to hold down Command+Alt+O+F while booting just to eject their CD... (weirdly enough the most frequent Open Firmware use case on Macs)
64-bit only?
A few of the words right now implicitly depend on machine word size to operate correctly.
I could write versions that worked on 32-bit, but I don't have a 32-bit machine to test on.