5 ms·

> They then go on to posit the use of meaningful whitespace. Something that is quite disgusting to me. Clearly not everyone agrees with this viewpoint, since P

> They then go on to posit the use of meaningful whitespace. Something that is quite disgusting to me. Clearly not everyone agrees with this viewpoint, since Python depends on it and is extremely popular. But if you don't want meaningful whitespace, that's fine. We actually devised three notations, each one a superset of the previous ones: * curly-infix-expressions (c-expressions) * Neoteric-expressions (n-expressions) * Sweet-expressions (t-expressions) Only the last one (sweet-expressions) is whitespace-sensitive. More info here: https://readable.sourceforge.io/ https://readable.sourceforge.io/

RoboTeddy 9y ago
This looks really nice! Are there any largish examples written with sweet-expressions? (Seeing large chunks of code could help with forming a gestalt impression)' Edit: found one - https://sourceforge.net/p/readable/code/ci/master/tree/src/sweeten.sscm https://sourceforge.net/p/readable/code/ci/master/tree/src/s...
taeric 9y ago
I'd be surprised if python is winning folks over because of the significant whitespace. More that it just is not a deciding factor. (Note, I'm specifically not saying it is popular despite the whitespace.) That is to say, yes, I recognize my opinion as just an opinion. Most of it is colored by bad experiences with large YAML files, I confess. My problem with the code is precisely that it tears down my notion of the code being nothing more than a list of data. As an example, in: (define (factorial n) (if (<= n 1) 1 (* n (factorial (- n 1))))) Everything that goes together is in the same list. Some things branch off of because they are part of another list. But all subexpressions are easily visible as just lists. I can take one out and try it somewhere else. How do I know they are lists? Because they look like every other list in the program. Begin and end with a paren. The "improved one": define factorial(n) if {n <= 1} 1 {n * factorial{n - 1}} How do I know it is over? How do I trace back to what part of the code is finished when I evaluated {n * factorial{n - 1}}? Hopefully, the code is short enough that these are obviously answered. However, I am well aware that sometimes this doesn't work. And, quite frankly, the brain power to find the matched paren is much less than the brain power to determine what lexical unit the compiler would have been in, and to scan up for the matching lexical unit. Then there is the contrarian in me that is probably just getting annoyed that they labeled the proposal as the "improved" piece of code. :D
- pka 9y ago
  I agree in general that sexps provide the best editing experience currently, but that's just a matter of tooling, it's not an inherent property of sexps vs infix or whitespace-dependent syntax. Check out [0], a structured editing mode for Haskell, a whitespace-sensitive language. Incidentally, while I have no problem with Lisps (I've used Clojure for about a year), I do prefer infix notation, precisely because it's not homogeneous. [0] https://github.com/chrisdone/structured-haskell-mode https://github.com/chrisdone/structured-haskell-mode
  - taeric 9y ago
    You likely prefer infix because it is familiar. It is amazing how much familiarity influences preference. And yes, tooling can help. For either case. I'm leaning towards simpler tooling, which means me towards s-exps. Mainly because a lot of time has passed, and evidence is structured editing just doesn't take off in other languages. And I don't see requiring tooling as an improvement.
    - dwheeler 9y ago
      Yes, familiarity influences preference, and infix is familiar. Almost all adults who develop software have had 12 to 20 years of practice using infix notation as a standard part of mathematics, and it's also a standard part of practically all programming languages except Lisp and Forth. It's possible to notate calculations without infix (obviously!), but that doesn't mean that people WANT to do it. It's absurd to fight against the worldwide standard of infix notation for standard math operations like "+". For most people, {2 * {3 + 4}} is easier to understand than (* 2 (+ 3 4)). If a Lisp reader simply treats {...} as a list, where the operator is the even positions, then you have the best of both worlds: standard infix notation combined with Lisp's ability to do quasiquoting, macros, etc.
- dwheeler 9y ago
  > How do I know it is over? In an indentation sensitive syntax, you simply look at the next line and see if it has more or less or equal indentation. Then you're done. That turns out to be extremely fast, because the eye/brain combination is exceedingly good at determining if something is left or right or something else. In traditional s expressions, to match things up you have to count the parentheses, which the brain is extremely bad at. In practice, the brain is so bad at this that we have to depend on complicated tooling to do the formatting for us. In a typical editor, that means that we depend on things like left-right distance anyway. Since people depend on indentation in the first place, making it syntactically relevant simply applies what people already do to the syntax itself.

RoboTeddy 9y ago

This looks really nice! Are there any largish examples written with sweet-expressions? (Seeing large chunks of code could help with forming a gestalt impression)' Edit: found one - https://sourceforge.net/p/readable/code/ci/master/tree/src/sweeten.sscm https://sourceforge.net/p/readable/code/ci/master/tree/src/s...

taeric 9y ago

I'd be surprised if python is winning folks over because of the significant whitespace. More that it just is not a deciding factor. (Note, I'm specifically not saying it is popular despite the whitespace.) That is to say, yes, I recognize my opinion as just an opinion. Most of it is colored by bad experiences with large YAML files, I confess. My problem with the code is precisely that it tears down my notion of the code being nothing more than a list of data. As an example, in: (define (factorial n) (if (<= n 1) 1 (* n (factorial (- n 1))))) Everything that goes together is in the same list. Some things branch off of because they are part of another list. But all subexpressions are easily visible as just lists. I can take one out and try it somewhere else. How do I know they are lists? Because they look like every other list in the program. Begin and end with a paren. The "improved one": define factorial(n) if {n <= 1} 1 {n * factorial{n - 1}} How do I know it is over? How do I trace back to what part of the code is finished when I evaluated {n * factorial{n - 1}}? Hopefully, the code is short enough that these are obviously answered. However, I am well aware that sometimes this doesn't work. And, quite frankly, the brain power to find the matched paren is much less than the brain power to determine what lexical unit the compiler would have been in, and to scan up for the matching lexical unit. Then there is the contrarian in me that is probably just getting annoyed that they labeled the proposal as the "improved" piece of code. :D

pka 9y ago
I agree in general that sexps provide the best editing experience currently, but that's just a matter of tooling, it's not an inherent property of sexps vs infix or whitespace-dependent syntax. Check out [0], a structured editing mode for Haskell, a whitespace-sensitive language. Incidentally, while I have no problem with Lisps (I've used Clojure for about a year), I do prefer infix notation, precisely because it's not homogeneous. [0] https://github.com/chrisdone/structured-haskell-mode https://github.com/chrisdone/structured-haskell-mode
- taeric 9y ago
  You likely prefer infix because it is familiar. It is amazing how much familiarity influences preference. And yes, tooling can help. For either case. I'm leaning towards simpler tooling, which means me towards s-exps. Mainly because a lot of time has passed, and evidence is structured editing just doesn't take off in other languages. And I don't see requiring tooling as an improvement.
  - dwheeler 9y ago
    Yes, familiarity influences preference, and infix is familiar. Almost all adults who develop software have had 12 to 20 years of practice using infix notation as a standard part of mathematics, and it's also a standard part of practically all programming languages except Lisp and Forth. It's possible to notate calculations without infix (obviously!), but that doesn't mean that people WANT to do it. It's absurd to fight against the worldwide standard of infix notation for standard math operations like "+". For most people, {2 * {3 + 4}} is easier to understand than (* 2 (+ 3 4)). If a Lisp reader simply treats {...} as a list, where the operator is the even positions, then you have the best of both worlds: standard infix notation combined with Lisp's ability to do quasiquoting, macros, etc.
dwheeler 9y ago
> How do I know it is over? In an indentation sensitive syntax, you simply look at the next line and see if it has more or less or equal indentation. Then you're done. That turns out to be extremely fast, because the eye/brain combination is exceedingly good at determining if something is left or right or something else. In traditional s expressions, to match things up you have to count the parentheses, which the brain is extremely bad at. In practice, the brain is so bad at this that we have to depend on complicated tooling to do the formatting for us. In a typical editor, that means that we depend on things like left-right distance anyway. Since people depend on indentation in the first place, making it syntactically relevant simply applies what people already do to the syntax itself.