3 ms·
You hit upon an important cleavage: features vs worst-case perf. A generous lexer supports partial input, syntax highlighting, helpful error messages, etc., whi
by ridiculous_fish 6y ago
You hit upon an important cleavage: features vs worst-case perf. A generous lexer supports partial input, syntax highlighting, helpful error messages, etc., while a strict one is not so nice, but guarantees protection against malicious input. But the way you write these are very different! I also would like to write one lexer that can operate in both modes, but with one syntax.
BTW, high five from one shell author to another :)
- chubot 6y agoYeah I've been looking at fish. Definitely has the cleanest code out of any shell I've looked at :) (e.g. bash, dash, zsh, mksh) And I came to realize what a huge effort it is on top of the language: http://www.oilshell.org/blog/2020/02/recap.html#fish-oil-is-a-good-idea-link http://www.oilshell.org/blog/2020/02/recap.html#fish-oil-is-... Also I wonder if you knew of the existence of ble.sh, a fish-like UI written in pure bash! I think it's the biggest shell program in the world: http://www.oilshell.org/cross-ref.html?tag=ble.sh#ble.sh http://www.oilshell.org/cross-ref.html?tag=ble.sh#ble.sh https://github.com/oilshell/oil/wiki/The-Biggest-Shell-Programs-in-the-World https://github.com/oilshell/oil/wiki/The-Biggest-Shell-Progr... ---- I did add little hack in the lexer for autocompletion of partial input. But my hope though is to keep most of that logic in the parser and not the lexer? Though it is true I was thinking of breaking up the exact regex we talked about for similar reasons, e.g. a single token: ' [^']* ' vs. 3 tokens ' [^']* ' I think the latter could be better for completion of paths in quotes, which bash does, but I haven't revisited it yet.