There's some annoyance after "honeymoon" period, but it's mostly about additional parens being hard to track with eyes - no complaints related to semantics.
Conversation
We'll reduce the number of parens we print to mitigate that issue and then reevaluate how many problems the tuples being (like, this) still cause.
1
I do need to keep my pre-existing biases in check here too, and it's good you're having a go at challenging the status quo.
1
How hard would it be to create an alternate, Elm-style syntax for Reason? As somebody who writes a great deal of Rust, I kind of feel type signatures on top make much more sense for a type-driven programming style, as does dropping parens. Makes the code much cleaner and lighter.
3
1
1
Sweet. Would be interesting to see how people react to comparisons if they could easily switch between them!
3
Easiest of course is going to be an s-expression based alternative syntax because the parsers/printers are so darn trivial to write.
2
2
Would people actually use that, though? s-expressions are so painful to actually use, in practice; I'd rather see an F# style whitespace dependent syntax
1
It sounds impractical, but maybe there's something about going *all in* on the s-expression style as opposed to ML which is only partially so.
2
1
Yikes! I sure hope you don't adopt S-expression syntax -- as far as adoption goes, you're looking at an almost certain failure scenario. I think you're making this too complicated, application should associate to the left and people should be able to use parens when they want to.
2
It might make sense as the core representation of the syntax tree, but I don't think they'd do that unless they could switch easily between concrete syntaxes first.