I decided to see what would happen if I start with line-expression ideas but avoid indentation sensitivity: https://github.com/mflatt/racket2-rfcs/blob/sapling/text/0005-sapling.md

Other than the name, which is brilliant, this is an abomination :wink:

I’m excited to fully read it and understand it.

@mflatt @jeapostrophe There have now been four surface syntax proposals, each with their own Motivation section describing the limitations of s-expressions. What do you think about adding a standalone doc that summarizes these limitations? I think it would help people understand why we’re considering alternate surface syntaxes.

I accidentally pushed to racket/racket2-rfcs and then force-pushed to unwind. Apologies, and I hope I didn’t break anything terribly. It made 117 claim to be merged, which was obviously not the intent and back to not being the case.

@notjack That does sound useful for reference by all proposals. I’m skeptical that it will help anyone understand the motivation, though; while it could be written down nicely one more time, people already know the benefits and limitations of S-expressions.

@mflatt I think there’s a lot of value in having something we can point people to when they ask “what’s wrong with s-expressions?!”, especially if they’re asking out of frustration. It’s good to show our thought process, even if it seems obvious. Makes it easier to trust.

@mflatt looks good, with my Elixir glasses on :+1: For the typed example (interp.sap) is the format always ident_:_type, i.e space is mandatory around the colon?

The space is not necessary.

FWIW I’m looking at the case of using the same syntax for an embedded scheme runtime (owl or ol) as well as racket, so I’m very happy with this discussion and its potential to lower the barriers of entry to more s-exp languages :slightly_smiling_face:

@notjack this is a great idea. Thanks for volunteering ;)