I'm really excited to see how rhombus turns out, and can't wait too see how they resolve some of the hairier design decisions around building a form-based language with implicit forms. (Shrubbery seems interesting.)
As an aside, I'm working on a different new programming language that supports language-level programming through a macro/effect system (and doesn't use s-expressions). In practice, Macro systems work well on any language that has the concept of 'forms' (see: Homoiconicity isn’t the point)
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.
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.
I think it's like you said. We will just have to wait and see. You are not the only one that has voiced their apprehension about moving away from S-expressions. One thing I really appreciate about the Racket Team is their commitment to reducing the barrier to entry into the language. Whether it's the Documentation, A built in IDE for the language, package manager, binary downloads directly from the website, or moving away from mailings lists and Google Groups to Discourse. You could even say that moving on top of Chez Scheme to reduce the amount of C code to maintain is also reducing the barrier. It's easier to get into Racket in 2022 then it has been at any point in time. Especially if you aren't familiar with Lisps like I was a few years ago.
I think this is another move in that direction. If it fails, then we will have a strong data point into why Lisps are just better for some things. But the team is dedicated to not just doing things the old way and we've gotten so much good from that mode of thinking that I'm excited to follow this process whether it fails or not.
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.
To explore ways of bringing Lisp to wider ranges of audiences, I prefer indentation based syntax like:
->
range 100
map $ fn (x)
* x x
foldl 0 &+
println
which is S-Expressions with indentations, with in-line paren pairs. It looks a lot like Python by still using prefixed operators and it's still S-Expressions after parsing to remain homoiconic.
I've used something like this for Lisp-family languages privately for decades.
[1] I like having a bar | open a parenthesis that closes automatically when the line or group ends.
[2] There are many Lisp/Scheme constructions that jump two deep without an intervening symbol. Rather that having to count out indents, it's very helpful and readable to have a dummy symbol as skeleton to reify the parenthesis structure. I like $ from Haskell.
You are right. When tools are not being friendly to indentation based syntax, the code with indentations would be a mess. Parentheses and curly braces are lot like "defensive programming" against unfriendly tools.
Racket's programmability goes far beyond Julia's. Racket is really a platform for programming languages rather than being primarily a programming language. For an example of what this looks like in practice, check out Rosette, a programming language in Racket which completely changes the semantics to work transparently with tooling like Z3.
Yeah, Julia can only take metaprogramming so far given its non-S-expr syntax - which is the right tradeoff given its domain. Its macros have to be given at least vaguely Julia-like syntax - `*` still needs to be a binary operator, `if`s need `end`s, etc. That's great for nice little DSLs appropriate for the scientific domain, but not quite enough for a "platform for programming languages". (It also has "string macros", which can accept anything at all, but basically give you a lump of string at compile time, and leave the tokenization, parsing, and any further manipulation up to your macro.)
I'm really excited to see how rhombus turns out, and can't wait too see how they resolve some of the hairier design decisions around building a form-based language with implicit forms. (Shrubbery seems interesting.)
As an aside, I'm working on a different new programming language that supports language-level programming through a macro/effect system (and doesn't use s-expressions). In practice, Macro systems work well on any language that has the concept of 'forms' (see: Homoiconicity isn’t the point)
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.
I think it's like you said. We will just have to wait and see. You are not the only one that has voiced their apprehension about moving away from S-expressions. One thing I really appreciate about the Racket Team is their commitment to reducing the barrier to entry into the language. Whether it's the Documentation, A built in IDE for the language, package manager, binary downloads directly from the website, or moving away from mailings lists and Google Groups to Discourse. You could even say that moving on top of Chez Scheme to reduce the amount of C code to maintain is also reducing the barrier. It's easier to get into Racket in 2022 then it has been at any point in time. Especially if you aren't familiar with Lisps like I was a few years ago.
I think this is another move in that direction. If it fails, then we will have a strong data point into why Lisps are just better for some things. But the team is dedicated to not just doing things the old way and we've gotten so much good from that mode of thinking that I'm excited to follow this process whether it fails or not.
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.
To explore ways of bringing Lisp to wider ranges of audiences, I prefer indentation based syntax like:
which is S-Expressions with indentations, with in-line paren pairs. It looks a lot like Python by still using prefixed operators and it's still S-Expressions after parsing to remain homoiconic.
And my prototype language http://calcit-lang.org/ .
I've used something like this for Lisp-family languages privately for decades.
[1] I like having a bar | open a parenthesis that closes automatically when the line or group ends.
[2] There are many Lisp/Scheme constructions that jump two deep without an intervening symbol. Rather that having to count out indents, it's very helpful and readable to have a dummy symbol as skeleton to reify the parenthesis structure. I like $ from Haskell.
Haha! The irony; I found your comment in a HN search for Lisp.
In the search result, your painstakingly indented code appears flattened to the left margin, destroying the correctness of its structure.
https://i.imgur.com/jAB0tBn.png
Just, no.
You are right. When tools are not being friendly to indentation based syntax, the code with indentations would be a mess. Parentheses and curly braces are lot like "defensive programming" against unfriendly tools.
The metaprogramming capabilities seems quiet similar to Julia's, I wonder how they will differ by the end.
Racket's programmability goes far beyond Julia's. Racket is really a platform for programming languages rather than being primarily a programming language. For an example of what this looks like in practice, check out Rosette, a programming language in Racket which completely changes the semantics to work transparently with tooling like Z3.
Yeah, Julia can only take metaprogramming so far given its non-S-expr syntax - which is the right tradeoff given its domain. Its macros have to be given at least vaguely Julia-like syntax - `*` still needs to be a binary operator, `if`s need `end`s, etc. That's great for nice little DSLs appropriate for the scientific domain, but not quite enough for a "platform for programming languages". (It also has "string macros", which can accept anything at all, but basically give you a lump of string at compile time, and leave the tokenization, parsing, and any further manipulation up to your macro.)
> Its macros have to be given at least vaguely Julia-like syntax
That’s true with Lisp as well. The point of homoiconicity is that your DSL looks like your parent language.
That said, Julia supports string macros. See for example “APL.jl” for a macro of to compile APL to Julia.