4 ms·

It's somewhat difficult to come up with a good syntax. You need to support: unquoted strings, executing commands, pipes, file redirects, etc. Adoption would be

It's somewhat difficult to come up with a good syntax. You need to support: unquoted strings, executing commands, pipes, file redirects, etc. Adoption would be even harder, but any resulting language is not going to look like Python or any other "mainstream" language, if it's intended to actually be usable.

chubot 10y ago
Yeah this is a problem, but after writing a bash parser I think it's straightforward to solve. Oil is parsed line by line like any other shell, and there will be a simple rule to determine whether you're in command mode or expression mode. The "lexer modes" technique (previous referred to as "lexical state") should handle the two sublanguages easily. You basically need it to parse bash, and you will need much less of it to parse oil. My bash parser has 13 lexical states (up from 8), but I expect oil to have somewhere between 4 and 8. How it's used in the bash parser: http://www.oilshell.org/blog/2016/10/19.html http://www.oilshell.org/blog/2016/10/19.html
- hyperpape 10y ago
  I'm not talking about implementation, but rather designing a clear and consistent syntax. It sounds like your intent is to hew pretty closely to existing shells, in which case you're probably doing more detail work.
  - chubot 10y ago
    The strategy is to break compatibility with bash but provide an upgrade path, as mentioned here: https://news.ycombinator.com/item?id=13478291 https://news.ycombinator.com/item?id=13478291 It is a design issue to combine command and expression syntax (unquoted and vs. quoted literals). But I think I've figured it out ... we'll see in a few months! The blog will have updates on these kinds of issues.
    - hyperpape 10y ago
      But are you maintaining POSIX compatibility? I thought I'd read that somewhere on your blog, but I might misremember.
      - chubot 10y ago
        Yes, the osh language is basically bash, which is very compatible superset of POSIX sh. The oil language is a totally different language, but you will be able to upgrade to it automatically. Once you upgrade it's of course not POSIX compatible anymore :)

chubot 10y ago

Yeah this is a problem, but after writing a bash parser I think it's straightforward to solve. Oil is parsed line by line like any other shell, and there will be a simple rule to determine whether you're in command mode or expression mode. The "lexer modes" technique (previous referred to as "lexical state") should handle the two sublanguages easily. You basically need it to parse bash, and you will need much less of it to parse oil. My bash parser has 13 lexical states (up from 8), but I expect oil to have somewhere between 4 and 8. How it's used in the bash parser: http://www.oilshell.org/blog/2016/10/19.html http://www.oilshell.org/blog/2016/10/19.html

hyperpape 10y ago
I'm not talking about implementation, but rather designing a clear and consistent syntax. It sounds like your intent is to hew pretty closely to existing shells, in which case you're probably doing more detail work.
- chubot 10y ago
  The strategy is to break compatibility with bash but provide an upgrade path, as mentioned here: https://news.ycombinator.com/item?id=13478291 https://news.ycombinator.com/item?id=13478291 It is a design issue to combine command and expression syntax (unquoted and vs. quoted literals). But I think I've figured it out ... we'll see in a few months! The blog will have updates on these kinds of issues.
  - hyperpape 10y ago
    But are you maintaining POSIX compatibility? I thought I'd read that somewhere on your blog, but I might misremember.
    - chubot 10y ago
      Yes, the osh language is basically bash, which is very compatible superset of POSIX sh. The oil language is a totally different language, but you will be able to upgrade to it automatically. Once you upgrade it's of course not POSIX compatible anymore :)