Hacker News Reader

Comment by badtuple | Hacker News Reader

Serious question: Why do parens matter so much?

I read the post and all the comments here, where people are very adamant about their opinions on parens. It seems to me that while syntax is important, parens in this context is about as close to "just syntax" as we can get. Racket-sans-parens would still be Racket.

Am I missing something fundamental?

View on HN

From a practical standpoint, basing everything off balanced parens (or square brackets, that makes no difference to me) makes the language much easier to write in. Being able to jump to the matching paren makes it trivial to copy/paste blocks of code, delete code, replace code, etc. It's so much easier than with things like Python. For instance, from the first line of a block of racket, copying that block in vim (not an editor known for being well suited for lisp) is as simple as %y. How do you do that in Python? If you know you're after 5 lines you could do 5Y, but that requires you to count how many lines you're after. You could use visual selection mode with V and then highlight the relevant lines, but that is more keystrokes than %y. You can get extensions for vim that create concise movements for dealing with indented blocks of python code, but with lisp no such extension is necessary. Even in vi-compat mode or things like Busybox's vi implementation that has no extension support, % works.

What's it like for C? A little bit better than python, but worse than lisp. Consider this block of code:

    if (foo) {
    ...
    }

How can I yank that entire thing, if my cursor is on the first character of the first line? The obvious answer to me is v$%y, which is pretty convenient, it doesn't require counting, but it's also fragile. What if that opening squiggly brace was on a new line? Then I'd have to do something like vj%y

As far as I'm concerned, despite vim being considered a second rate editor at best for lisp, lisp is arguably still the language vim is best suited for, and that's entirely a consequence of the fundamental usefulness of s-expressions.

IMHO the main problem are macros. Macros in racket/scheme/lisp/clojure are very powerful. You have the complete language available to make any transformation you want.

The idea is that the language look like an AST written as a list of list, and the tools to write macros look like some pattern matching to transform lists of list into lists of list. (In spite they are not lists of list but syntax objects that have much more information.) (And you are not forced to use some subset of tools, you can write arbitrary code in the macros, but some tools make the common tasks easier.)

For example, to create a new macro that run some block of code n times, you can write

  (define-syntax-rule (repeat n boby ...)
    (for ([i n])
      body ...))

and now you can use that as if it is part of the language:

  (repeat 5
    (displayln "Hello, Word!")
    (displayln "------------"))

(Note that, you don't have to worry that the counter i in the macro will overwrite a variable i in the main part of the code.)

Nobody is sure where is the magic, but writing macros is easies because the code in the main program and the patterns in the macro look very similar.

It's more difficult to work with a language with more syntax. Is the code desugared before going to the macro? Can you use some sugared version inside the macros? Does the user have to learn the main sugared version of the language and then learn the desugared forms?

What if one of the "arguments" of the macro is an infix operator? How does it interact with the other operators?

What if you have two interoperable languages running side by side? Racket ships with something like 10 or 20 internal languages, and you can download 5 or 10 or 20 or 1000 more. And all of them are (somewhat) interoperable. So you can most of the time use the libraries written in one of them in the other. You can even share macros between languages.

What if you have two interoperable languages running side by side? What if you write a macro in the sugared language and try to use in the other, or vice versa? Does they work? How?

Nobody is sure about the details, but Matthew is optimistic that this is possible, and he is usually right.

At least in Julia, which is a Lisp-inspired language without s-expressions, what you have is a dual representation for all code [1] in which you can manipulate either directly on the normal infix notation with quote and unquote, which is good for code injection [2], or in the s-expression-like representation (Surface syntax AST) [3] in which you have the full control over the structure but you have to deal with a different syntax. Using the s-expression-like is more powerful, but for the function user it doesn't really matter which you use.

[1] https://docs.julialang.org/en/v1/manual/metaprogramming/inde...

[2] https://docs.julialang.org/en/v1/manual/metaprogramming/inde...

[3] https://docs.julialang.org/en/v1/devdocs/ast/#Surface-syntax...

The semantics are much, much, more important for sure.

I think the “language oriented programming” semantics of Racket are brilliant.

I’ve been working on this syntax question for 7 years, now full time at the Tree Notation Lab. I think there is a better way to do the syntax, which over time will have strong network effects, which will allow us to code faster and have more reliable code. But you are right, perhaps this will just lead to a 20% across the board improvement in programmer productivity—-the bigger improvements will always come in the semantic realm. I think the thing to keep in mind is that only a tiny amount of people are focused on the syntax issues, they just like to shout at each other.

Reply on news.ycombinator.com