Comment by skybrian
4 years ago
Here is a description of shrubbery syntax: https://github.com/mflatt/rhombus-prototype/blob/shrubbery/s...
4 years ago
Here is a description of shrubbery syntax: https://github.com/mflatt/rhombus-prototype/blob/shrubbery/s...
I've seen the talks from RacketCon about it, but I was not impressed this time. They never talk about ergonomics of editing code properly. With S-expressions I can always select any expression or sub expression, because there is a clear start and end marker. This is probably about tooling. You could probably build some language support for that for shrubbery syntax, but it is going to be hairy. I am not convinced support for that will ever be as good as the code editing experience with S-expressions. That is why already the readme makes me think: "No!":
> Another disadvantage of S-expressions is that many of the parentheses are redundant after the expression is pretty-printed, because indentation provides the same grouping information in a more human-readable way.
The parentheses are not redundant at all! They are useful markers for selecting, cutting, pasting source code. I have mentioned this on the mailing list before, when there was discussion about moving away from S-expressions.
I get it, they want to keep an open mind and research other syntax. That's fine and good! But don't act, as if the parentheses are redundant and of no use. Find something better that supports the same level of code editing ease, then come back and present. I think it might even be impossible to do that, because you will still need those start and end markers, whatever they look like, or build the tooling, that has so deep understanding of the language's syntax, that it can "read your mind" and select the correct parts.
I will keep an open mind for when they surprise me and come around with something, that checks all the boxes.
Modern editors have good support for many languages that don't use S-expressions. Have you tried out VS Code?
I think for this effort to succeed, they only need to do as well with editor support as other mainstream languages.
No offense, but editing mainstream language's code is a pain compared to working with S-expressions. If they manage to get merely to that level of code editing convenience, they can keep their new syntax, I'm gonna stick to S-expressions.
I often see people using VS Code editing code. To me it often looks painful and I have the urge to do the code editing myself in Emacs with all my key bindings and good S-expression support. I have seen people being even much faster than me as well, with extra commands they define for moving S-expressions around and paredit and so on. Maybe VS Code can somehow be configured to offer the same comfort in code editing. I have not seen it done so far.
1 reply →
Indentation based optimises for reading and sexpr based optimises for writing/editing.
The syntax here looks isomorphic to sexpr. If so, one could program by reading the | based form, then convert the whole file to sexpr to edit it, then pretty print back to indent form when done. Better if the parens only replace the | and whitespace on the conversion so the cursor doesn't jump.
I'm not sure I like that but it is a somewhat interesting design point.
All but the most inexperienced lispers read code by indentation.
Also, pretty much any language that parses to an AST could easily output same as s-expressions if desired. Which incidentally is something I enjoy so much about Lisp. It makes it trivial to reason about code as a tree of structured objects instead of a string.
I'm a little worried about this as well as a Racket user. However, I also don't think it's impossible to make a macro system as intuitive as S-expressions with a well-designed language and tooling.