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)
https://www.oilshell.org/blog/2020/07/blog-roadmap.html#how-...
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:
http://www.oilshell.org/blog/2019/06/17.html#why-is-it-writt...
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:
https://www.oilshell.org/release/0.9.2/ (scroll down to "Source Code")
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:
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
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)
----
pyp looks interesting, I added it here under Awk-like DSLs: https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell