3 ms·

What doesn't work well for C-like languages? I've been writing a lot of Rust lately with Smartparens (a paredit like package in Emacs) and haven't had any issu

What doesn't work well for C-like languages? I've been writing a lot of Rust lately with Smartparens (a paredit like package in Emacs) and haven't had any issues with its support for Rust.

snazz 6y ago
We're talking about putting the closing brace on the same line of an expression, like this: int double(int x){ return x * 2;} instead of like this: int double(int x) { return x * 2; } In Lisp, you would write that like this: (defun double (x) (* 2 x)) and not this: (defun double (x) (* 2 x) ) You can read either with syntax highlighting and the appropriate indentation, but it's much harder to get away with putting the closing brace on the same line in C-like languages because of how few people use something like Smartparens or Paredit and how having multiple kinds of brackets (parens, square brackets, curly braces, and angle brackets) introduces ambiguity.
- codesections 6y ago
  Yeah, I understood what we were talking about – sorry for not being more clear in my reply earlier. When you said that putting the closing bracket on the same line wouldn't work because of the "lack of Paredit-style editor support" for C-like languages, I thought you meant that the Paredit-style plugins wouldn't work well with/support C-like languages. That struck me as odd, because I use Smartparens when writing Rust, and it works just as well as it does when I write a lisp/scheme. In particular, it handles parens, square brackets, curly braces, and angle brackets just fine (and it even distinguishes between a single quote that's used to start a character literal (which should be paired) and a single quote that indicates a lifetime label (which should not))[0]. I could easily use it to write Rust with closing braces on the same line; the only reason I don't is because it's not the common style in that community. Based on your last comment, I now understand that you're not saying Paredit-style plugins don't _work_ with C-like languages. You're saying that most programmers who write in those languages don't use those plugins. Is that right? If so, I agree that they aren't widely used and that it'd be hard for anyone to use the formatting style above without adopting a plugin. [0]: The only thing Smartparens fails to handle is that it does not recognize that a pipe character is a pair when delimiting the arguments for a closure. I'm sure I could fix either Smartparens or rust-mode to fix that issue but so far I haven't been annoyed enough to bother. [Edited to add a missing close-paren, fittingly enough.]
  - neutronicus 6y ago
    Paredit with Lisp is really slick for moving stuff (including yourself) around the AST. What you're describing, the auto-matching, is really just the tip of the iceberg. With Paredit, there are key chords for moving up, down, and sideways (forwards and backwards) on the tree of Sexps, for transposing two sibling Sexps, for grabbing a sibling (before or after) of a Sexp and making it a child ("slurping"), for taking a child of Sexp and making at a sibling ("barfing"). I have not found a reliable way to slurp statements into the scope of an if statement (Paredit kind of works but tends to misplace semicolons and various other things).
  - snazz 6y ago
    My bad with the poor communication up above. Turns out that we were basically in agreement the whole time. I'm impressed that it can handle the single-quote label thing; that strikes me as the exact sort of thing that I would think a tool like that would have trouble with.
- ken 6y ago
  Lisp programmers lived without Paredit just fine for many decades. Even if we assume that developers aren't clever enough to write a Paredit extension for their editors/IDEs for curly-brace languages, I don't see how that's a problem if this style of coding were truly superior for those types of languages.
- kazinator 6y ago
  I experimented with such a C style once, years ago; it was perfectly workable in Vim. The opening curly brace is better like this: int double(int x) { x += 3; return x * 2; } I found it's good to have spaces within the braces, including when closing them: int double(int x, int b) { if (b) { x += 3; return x * 2; } else { x -= 3; return x * 4; } } This naturally jives with a two space indentation, so everything is pleasingly copacetic. I feel I could easiy maintain a 200KLOC code base in this style. Oh, incidentallly, this style is followed in the production rule action bodies of the TXR yacc file parser.y: http://www.kylheku.com/cgit/txr/tree/parser.y http://www.kylheku.com/cgit/txr/tree/parser.y I wonder how well GCC's newer "misleading indentation warnings" handle this, though. > C-like languages because of how few people use something like Smartparens or Paredit However, everyone in C (or C-like) programming with two brain-cells to rub together uses at least auto-indention and brace/bracket/paren matching features in their editor. A stock installation of Vim turns some of it on by default if you open anything with a given suffix like .c or .js. These editing features work equally well regardless of how you lay out the braces.

What doesn't work well for C-like languages? I've been writing a lot of Rust lately with Smartparens (a paredit like package in Emacs) and haven't had any issues with its support for Rust.

snazz 6y ago

We're talking about putting the closing brace on the same line of an expression, like this: int double(int x){ return x * 2;} instead of like this: int double(int x) { return x * 2; } In Lisp, you would write that like this: (defun double (x) (* 2 x)) and not this: (defun double (x) (* 2 x) ) You can read either with syntax highlighting and the appropriate indentation, but it's much harder to get away with putting the closing brace on the same line in C-like languages because of how few people use something like Smartparens or Paredit and how having multiple kinds of brackets (parens, square brackets, curly braces, and angle brackets) introduces ambiguity.

codesections 6y ago
Yeah, I understood what we were talking about – sorry for not being more clear in my reply earlier. When you said that putting the closing bracket on the same line wouldn't work because of the "lack of Paredit-style editor support" for C-like languages, I thought you meant that the Paredit-style plugins wouldn't work well with/support C-like languages. That struck me as odd, because I use Smartparens when writing Rust, and it works just as well as it does when I write a lisp/scheme. In particular, it handles parens, square brackets, curly braces, and angle brackets just fine (and it even distinguishes between a single quote that's used to start a character literal (which should be paired) and a single quote that indicates a lifetime label (which should not))[0]. I could easily use it to write Rust with closing braces on the same line; the only reason I don't is because it's not the common style in that community. Based on your last comment, I now understand that you're not saying Paredit-style plugins don't _work_ with C-like languages. You're saying that most programmers who write in those languages don't use those plugins. Is that right? If so, I agree that they aren't widely used and that it'd be hard for anyone to use the formatting style above without adopting a plugin. [0]: The only thing Smartparens fails to handle is that it does not recognize that a pipe character is a pair when delimiting the arguments for a closure. I'm sure I could fix either Smartparens or rust-mode to fix that issue but so far I haven't been annoyed enough to bother. [Edited to add a missing close-paren, fittingly enough.]
- neutronicus 6y ago
  Paredit with Lisp is really slick for moving stuff (including yourself) around the AST. What you're describing, the auto-matching, is really just the tip of the iceberg. With Paredit, there are key chords for moving up, down, and sideways (forwards and backwards) on the tree of Sexps, for transposing two sibling Sexps, for grabbing a sibling (before or after) of a Sexp and making it a child ("slurping"), for taking a child of Sexp and making at a sibling ("barfing"). I have not found a reliable way to slurp statements into the scope of an if statement (Paredit kind of works but tends to misplace semicolons and various other things).
- snazz 6y ago
  My bad with the poor communication up above. Turns out that we were basically in agreement the whole time. I'm impressed that it can handle the single-quote label thing; that strikes me as the exact sort of thing that I would think a tool like that would have trouble with.
ken 6y ago
Lisp programmers lived without Paredit just fine for many decades. Even if we assume that developers aren't clever enough to write a Paredit extension for their editors/IDEs for curly-brace languages, I don't see how that's a problem if this style of coding were truly superior for those types of languages.
kazinator 6y ago
I experimented with such a C style once, years ago; it was perfectly workable in Vim. The opening curly brace is better like this: int double(int x) { x += 3; return x * 2; } I found it's good to have spaces within the braces, including when closing them: int double(int x, int b) { if (b) { x += 3; return x * 2; } else { x -= 3; return x * 4; } } This naturally jives with a two space indentation, so everything is pleasingly copacetic. I feel I could easiy maintain a 200KLOC code base in this style. Oh, incidentallly, this style is followed in the production rule action bodies of the TXR yacc file parser.y: http://www.kylheku.com/cgit/txr/tree/parser.y http://www.kylheku.com/cgit/txr/tree/parser.y I wonder how well GCC's newer "misleading indentation warnings" handle this, though. > C-like languages because of how few people use something like Smartparens or Paredit However, everyone in C (or C-like) programming with two brain-cells to rub together uses at least auto-indention and brace/bracket/paren matching features in their editor. A stock installation of Vim turns some of it on by default if you open anything with a given suffix like .c or .js. These editing features work equally well regardless of how you lay out the braces.