> Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline

> Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline tree like code does come in handy there. This is a really good point. I'm thinking of experimenting with a convention for doing inline trees using Tree Notation. In the code itself the delimiters are called YI (newline) and XI/ZI (space), so potentially could do something like this for the REPL: (set YI="|" ... "def square x|return|* x x " > Lastly, I'd say copy/pasting can be annoying in whitespace sensitive syntaxes. This is true. Things that minimize it in Tree Notation: no ambiguity with spaces/tabs/indent levels--one space is the only way to indent things; great syntax highlighters & automatic suggested fixes (I've got a todo to add autosuggested fix the common case where subsequent lines are de-dented after a paste); and the ubiquity of multi/vertical cursors in editors nowadays. Still, whether I'm using Sublime or VS Code or vim, indent can sometimes be an issue. I think it's just a matter of having all the grunt work done for the modes in these languages to ensure things work as you'd expect. I bet we get that all done by end of year at latest. > my brain adapted and now I find S-expressions superior in all ways to all other syntaxes I've ever used. I think largely the same way, except to me just swap S-Expressions with Tree Notation (which is just SE w/o parens). But that's only because the tooling is getting there now. When I look back at where things were in 2017, wow, Tree Notation was very hard to use back then.