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.
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.
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.
2 replies →
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.
1 reply →
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.)
1 reply →