3 ms·

I've been trying to build a computer with a single principled HLL included that can also double as a shell. There's also http://www.oilshell.org http://www.oils

I've been trying to build a computer with a single principled HLL included that can also double as a shell. There's also http://www.oilshell.org http://www.oilshell.org which _also_ tries to be compatible with existing shell. It also tries to include features from awk and sed: https://www.oilshell.org/blog/2016/11/13.html https://www.oilshell.org/blog/2016/11/13.html If these design points turn out to be over-constrained and have to make major compromises, yes the next thing I would try would be a small separate language for shell.

chubot 6y ago
BTW I think the general idea of Oil's syntax is working out: start in "command mode", and then when you see the RHS of =, changing modes to Python-/JS- like expressions. There a few other cases where you switch to expression mode, like proc p(a, b) [1] So far nobody has complained about any of this, I'm guessing because it looks very familiar, and that was intentional. Oil takes some pains to literally look like shell + Python syntactically, with better semantics. I noticed that a few other shells are having problems with this command/expression distinction, and I discussed it like 3-4 years ago with Ilya Sher (of NGS) and a few other people. They were also having the same problem. For example, does / mean a path separator or the division operator? Does * mean a glob or a multiplication? In Oil, this is no problem. It's obvious depending on the context. Though I'm interested in more feedback on this, and the latest release is available to try as always :) https://www.oilshell.org/release/latest/ https://www.oilshell.org/release/latest/ --- The awk and make integration is still doable but not done. Awk might require a notion of "lazy expressions" or "lazy arg lists", which would be shared with dplyr-like functionality. Oil's Zulip is open for discussion on these ideas :) [1] https://www.oilshell.org/release/0.8.5/doc/command-vs-expression-mode.html https://www.oilshell.org/release/0.8.5/doc/command-vs-expres...

chubot 6y ago

BTW I think the general idea of Oil's syntax is working out: start in "command mode", and then when you see the RHS of =, changing modes to Python-/JS- like expressions. There a few other cases where you switch to expression mode, like proc p(a, b) [1] So far nobody has complained about any of this, I'm guessing because it looks very familiar, and that was intentional. Oil takes some pains to literally look like shell + Python syntactically, with better semantics. I noticed that a few other shells are having problems with this command/expression distinction, and I discussed it like 3-4 years ago with Ilya Sher (of NGS) and a few other people. They were also having the same problem. For example, does / mean a path separator or the division operator? Does * mean a glob or a multiplication? In Oil, this is no problem. It's obvious depending on the context. Though I'm interested in more feedback on this, and the latest release is available to try as always :) https://www.oilshell.org/release/latest/ https://www.oilshell.org/release/latest/ --- The awk and make integration is still doable but not done. Awk might require a notion of "lazy expressions" or "lazy arg lists", which would be shared with dplyr-like functionality. Oil's Zulip is open for discussion on these ideas :) [1] https://www.oilshell.org/release/0.8.5/doc/command-vs-expression-mode.html https://www.oilshell.org/release/0.8.5/doc/command-vs-expres...