For context, I wrote this doc after making a bunch of simplifying changes:
Got rid of the set and setlocal keywords entirely! Long story, but I couldn’t “explain them with a straight face”, and they were too focused on legacy shell behavior. We now have 2 keywords for declaration (var and const) and 3 for mutation (setvar, setglobal, setref).
Got rid of dynamic scope entirely! This now includes all builtins like read and unset. Oil behaves more like Python or JavaScript.
Got rid of bad “static” checks at the top level
Tightened up the setref keyword, which is the “escape hatch” for mutating the parent scope.
Writing the doc is the exercise in “documentation driven development”, i.e. can this be explained cleanly? :) I’m looking for feedback!
Thanks for posting this, I always look forward to your updates on Oil. How are you feeling burnout-wise? Are there enough folks working with you that you aren’t spread too thing?
Good question, I have been meaning to write a project retrospective but haven’t had time :-P
Right now I feel pretty good about things. I’ve taken a bunch of breaks lately, and after a break I feel pretty productive.
A very recent development which I haven’t blogged about is “headless mode” [1], which is a scheme to separate the shell into UI process and a language/interpreter process.
This came out of discussions with a collaborator who is writing a shell GUI. If you want a mental picture you can imagine a shell UI that looks like a browser – it has a command line that’s like a URL bar, and then each command is run in its OWN terminal. That’s not the only thing you could build, but it’s one of them.
The slogan is that shell is a language- and text- oriented interface, but there’s no reason it has to be a TERMINAL- based one! (at least no exclusively)
I’m excited about this for a few reasons:
it cuts the scope of Oil proper. The shell UI is written in Go, and others can do the same in Rust, Swift, etc. All you need is a library that support descriptor passing over Unix sockets, and everything works very nicely. I’m surprised this pattern hasn’t been explored before (AFAIK)! Basically you can create a new terminal or pipe for every command, and pass it to the Oil process, which will use it.
It enables parallel development and design. I hope that a bunch of different UIs will be made. Given all the activity here (https://github.com/oilshell/oil/wiki/Alternative-Shells) I think that will happen. Some of them like xonsh are wrappers around bash, but headless mode is a way to wrap a shell in a more principled (and faster) way.
It gives people a reason to use Oil! It does seem like most people want something friendlier like fish.
I think the people who are writing the GUIs will give the Oil language a good workout, because you need some help from Oil to write the GUI (completion, etc.)
So things keep improving, which keeps me motivated. There were times when I was banging my head against the garbage collector, and I got frustrated. But it’s still making progress, and now I know a lot more about garbage collectors, which is fun :)
The project is inherently big, I’d divide it into roughly these equal-sized parts:
OSH language (running existing scripts)
Oil language
Making the whole thing faster (mycpp, etc.). This has been going on for just over 2 years, and is probably the thing with the most unknowns/surprises. I took a wrong turn early in the project, but I learned something.
Documentation
The Interactive Shell (history, completion, etc.)
So I think that pushing #5 outside the project is going to make things a lot more reasonable! That could be a years long effort in itself and I hope a lot of people will build on it. Most people don’t want to write an interpreter for .bashrc, but they want to use it!
Feel free to join oilshell.zulipchat.com and look at #shell-gui for the discussions around it. It’s still early but there are working prototypes!
[1] These links aren’t polished but may give you some background
For context, I wrote this doc after making a bunch of simplifying changes:
setandsetlocalkeywords entirely! Long story, but I couldn’t “explain them with a straight face”, and they were too focused on legacy shell behavior. We now have 2 keywords for declaration (varandconst) and 3 for mutation (setvar,setglobal,setref).setrefkeyword, which is the “escape hatch” for mutating the parent scope.Writing the doc is the exercise in “documentation driven development”, i.e. can this be explained cleanly? :) I’m looking for feedback!
Thanks for posting this, I always look forward to your updates on Oil. How are you feeling burnout-wise? Are there enough folks working with you that you aren’t spread too thing?
Good question, I have been meaning to write a project retrospective but haven’t had time :-P
Right now I feel pretty good about things. I’ve taken a bunch of breaks lately, and after a break I feel pretty productive.
A very recent development which I haven’t blogged about is “headless mode” [1], which is a scheme to separate the shell into UI process and a language/interpreter process.
This came out of discussions with a collaborator who is writing a shell GUI. If you want a mental picture you can imagine a shell UI that looks like a browser – it has a command line that’s like a URL bar, and then each command is run in its OWN terminal. That’s not the only thing you could build, but it’s one of them.
The slogan is that shell is a language- and text- oriented interface, but there’s no reason it has to be a TERMINAL- based one! (at least no exclusively)
I’m excited about this for a few reasons:
it cuts the scope of Oil proper. The shell UI is written in Go, and others can do the same in Rust, Swift, etc. All you need is a library that support descriptor passing over Unix sockets, and everything works very nicely. I’m surprised this pattern hasn’t been explored before (AFAIK)! Basically you can create a new terminal or pipe for every command, and pass it to the Oil process, which will use it.
It enables parallel development and design. I hope that a bunch of different UIs will be made. Given all the activity here (https://github.com/oilshell/oil/wiki/Alternative-Shells) I think that will happen. Some of them like xonsh are wrappers around bash, but headless mode is a way to wrap a shell in a more principled (and faster) way.
It gives people a reason to use Oil! It does seem like most people want something friendlier like fish.
I think the people who are writing the GUIs will give the Oil language a good workout, because you need some help from Oil to write the GUI (completion, etc.)
So things keep improving, which keeps me motivated. There were times when I was banging my head against the garbage collector, and I got frustrated. But it’s still making progress, and now I know a lot more about garbage collectors, which is fun :)
The project is inherently big, I’d divide it into roughly these equal-sized parts:
So I think that pushing #5 outside the project is going to make things a lot more reasonable! That could be a years long effort in itself and I hope a lot of people will build on it. Most people don’t want to write an interpreter for
.bashrc, but they want to use it!Feel free to join oilshell.zulipchat.com and look at #shell-gui for the discussions around it. It’s still early but there are working prototypes!
[1] These links aren’t polished but may give you some background
https://github.com/oilshell/oil/wiki/Headless-Mode
https://github.com/oilshell/oil/issues/738