Should lisp style formatting be used for tree-sitter-query files?

[mkatychev]

2. For the time being, I think we should stick with the Algol-style indentation, rather than Lisp-style. That is:

   ; Algol-style
   (foo
     (bar
       (quux)
     )
   )
   
   ; Lisp-style
   (foo
     (bar
       (quux)))

   I think there's a strong argument to switch to Lisp-style, but I think that warrants an issue -- feel free to create one -- so the Topiary Team can consider it.

Originally posted by @Xophmeister in #826 (review)

This issue is created to discuss using Lisp-style formatting for tree-sitter .scm files. I don't have a particularly strong stance but all community/official documentation outside of the topiary repo leans towards Lisp-style scopes.

[mkatychev]

@Xophmeister is now a good time to revisit this? I think topiary could see some good adoption if CI for treesitter repos if there was zero setup for it, ergo lisp style formatting by default as a GHA.

EDIT:
I think this is a small change but would really help in the adoption for using the tsq style used by 99% of the community (I've only seen algol style formatting in this repo TBH).
@yannham any thoughts?

[mkatychev]

I know a standalone GHA is not very nix-y but I would be motivated to write one if this change went through (I realize it's quite a tangential statement).

[Xophmeister]

Personally, I'm pro-Lisp-style. I suspect we originally went for Algol-style because of the "minimising diffs" design goal. However, another goal is to replicate styles attested in the wild and, imo, that wins in a tie.

@tweag/topiary-core-team Any other thoughts?

[yannham]

I don't have a strong personal opinion either. I might be slightly pro-lisp as well. In particular because, as mentioned in this issue originally, this is how tree-sitter formats its output in e.g. tree-sitter parse, which makes it easier IMHO to mentally map (or even concretely diff) parse trees and queries.

[nbacquey]

I'm slightly in favor of Algol-style, because Lisp might lead to some readability issues such as

; Lisp-style
(foo
  (bar
    (quux) @which_node) @is_tagged) @here

To properly decide, I think I'd like to know if we'd have this kind of aberration when formatting existing queries Lisp-style.
edit: I'm opening a draft PR so we can have a look

[nbacquey]

I'm slightly in favor of Algol-style, because Lisp might lead to some readability issues such as

; Lisp-style
(foo
(bar
(quux) @which_node) @is_tagged) @here

To properly decide, I think I'd like to know if we'd have this kind of aberration when formatting existing queries Lisp-style. edit: I'm opening a draft PR so we can have a look

Done in #932

[mkatychev]

@nbacquey I agree that that style is cleaner, I'm of the mind of prioritizing adoption over readability is all. If nobody uses a superior tool/config then it won't get any traction.

I'm highly indifferent to one style or the other, I just want more people to use topiary and this seems like one of the lowest hanging fruit.

[nbacquey]

I found this in the nickel file, and I really don't like it:

(_
  (#scope_id! "bound_rhs")
  "=" @append_spaced_scoped_softline @append_indent_start
  .
  (term
    .
    (uni_term
      .
      [
        ; There is scope for factoring these patterns with
        ; embedded alternations. Keeping them separate is probably more
        ; efficient to process and certainly easier to read.

        ; Record literals
        (infix_expr . (applicative . (record_operand . (atom . (uni_record)))))

        ; Array literals
        (infix_expr . (applicative . (record_operand . (atom . "["))))

        ; Enum literals
        (infix_expr . (applicative . (record_operand . (atom . (type_atom . "[|")))))

        ; Parentheticals
        (infix_expr . (applicative . (record_operand . (atom . "("))))

        ; Function declarations
        (fun_expr)

        ; Match statements
        (infix_expr . (applicative . (match_expr)))

        ; Multi-line and symbolic strings
        (infix_expr . (applicative . (record_operand . (atom . (str_chunks)))))]? @do_nothing)) @append_indent_end)

[Xophmeister]

It looks OK. There are some weird things that I initially notice:

• A terminating anchor looks a bit odd:

  (node
    (something)
    .)

• Groups start a new indentation block, whereas I think idiomatic Lisp would use column alignment (which Topiary can't do). Same for alternations:

  ; Group
  (
    (foo)
    (bar))
  
  ; Idiomatic group
  ((foo)
   (bar))
  
  ; Alternation
  [
    (foo)
    (bar)]
  
  ; Idiomatic alternation
  [(foo)
   (bar)]

  Some Lisps make exceptions for groups and format them Algol-style.

[nbacquey]

Note: We could always have two formats: one for "regular" tree-sitter queries, and one for topiary queries

[nbacquey]

Also, several instances of stuff like this:

(fun_expr
  (#scope_id! "function_definition")
  "=>" @prepend_begin_scope @append_indent_start) @append_indent_end @append_end_scope

[nbacquey]

It looks OK. There are some weird things that I initially notice:

• A terminating anchor looks a bit odd:

  (node
    (something)
    .)

• Groups start a new indentation block, whereas I think idiomatic Lisp would use column alignment (which Topiary can't do). Same for alternations:

  ; Group
  (
    (foo)
    (bar))
  
  ; Idiomatic group
  ((foo)
   (bar))
  
  ; Alternation
  [
    (foo)
    (bar)]
  
  ; Idiomatic alternation
  [(foo)
   (bar)]

  Some Lisps make exceptions for groups and format them Algol-style.

I think we could mimic column alignment with single-space indentation, probably.

[Niols]

Note: We could always have two formats: one for "regular" tree-sitter queries, and one for topiary queries

If we decide for algol style for Topiary queries, then yes, that sounds like the right thing to do.