Thank you for the extensive and thoughtful comment! This does help clarify your approach quite considerably. I wonder, since you are hoping to attract collaborators, whether there is some kind of formal spec for the language somewhere? For example, you mentioned parallel efforts: suppose I wanted to write a port to pure C; is there any way, short of reading every one of your posts and trying to contain the whole language in my head at once, for me to know exactly what I need to implement?
Something I've been trying to figure out: what is the exact relationship at present between OSH and Oil? When you say "OSH" do you mean the language, or the shell itself "oil shell"? If Oil is not something I can download, why exactly does that `const v = max(1, 2)` statement work in osh? It's clearly not just a Bash implementation, it's got other features. Is that a subset of Oil's features? Which subset?
Since you're also interested in other shells, you might have a look at pyp [1]. It captures a lot of the way I personally would like to use some future shell. If the features of pyp were integrated into the shell itself, you wouldn't need an external command, you could just (for example) pipe the output of one program into a python-like statement that mangles the incoming strings in some way, and pipe that out to some xargs-like program to use in a subshell. (The fact that you apparently can't use the pipe in what Xonsh calls "Python mode" is for me the central limiting feature of that shell.)
The algebraic data types alone give a huge leg up, but there's more than that. The spec is the code! That's why it's written in an unusual style with a high level language:
At the end of every release there are some links to key source files. At some point these could be nice HTML diagrams rather than raw source code, but the info is concisely encoded:
Also, I don't expect much of this to be intelligible at first... It's a bunch of pointers to start. Anyone who wants to go down this path this will have to ask a lot of questions on Zulip, which will motivate updates to the docs.
-----
I will write a FAQ about OSH vs Oil, since that has come up several times, and it has evolved over time.
There is only a single binary and single interpreter, but there are two entry points bin/osh and bin/oil, which basically correspond to the OSH and Oil languages.
So the interpreter is parameterized by parsing and runtime options. They are all under this group:
shopt --set oil:all # turn on everything as if you were running bin/oil
That is what this Tour doc refers to -- a shared interpreter data model, and a shared process model.
So we talk about them and document them as separate languages. But really it's a graceful upgrade of a single language. If you want you can even set individual options like shopt --set parse_paren.
-----
The syntax
const v = max(1, 2)
is valid in both bin/osh and bin/oil, since nobody has complained the taking 'const' breaks anything. (We try to minimize new keywords -- e.g. 'pass' was removed from the language based on feedback). Whether you want to consider it OSH or Oil is up for debate :) The meanings of OSH and Oil have slightly changed as the project evolves, but OSH means roughly "compatible features" and Oil means "new, incompatible features". It's a spectrum.
(I think I have written all of this in various places, but it does need to be put in a more central place on the site)
Something I've been trying to figure out: what is the exact relationship at present between OSH and Oil? When you say "OSH" do you mean the language, or the shell itself "oil shell"? If Oil is not something I can download, why exactly does that `const v = max(1, 2)` statement work in osh? It's clearly not just a Bash implementation, it's got other features. Is that a subset of Oil's features? Which subset?
Since you're also interested in other shells, you might have a look at pyp [1]. It captures a lot of the way I personally would like to use some future shell. If the features of pyp were integrated into the shell itself, you wouldn't need an external command, you could just (for example) pipe the output of one program into a python-like statement that mangles the incoming strings in some way, and pipe that out to some xargs-like program to use in a subshell. (The fact that you apparently can't use the pipe in what Xonsh calls "Python mode" is for me the central limiting feature of that shell.)
[1] https://github.com/hauntsaninja/pyp