Why the square brackets?

[kflak]

Hi,

I've started the long journey towards lisp-dom, and porting my supercollider stuff over to cl-collider is one of my projects for learning this... I've encountered a bug in tree-sitter, though, that makes it impossible to use tree-sitter together with cl-collider. The culprit is the use of square brackets. When running the example code with sbcl everything compiles nicely:

(ql:quickload :cl-collider)
(in-package :sc-user)
(named-readtables:in-readtable :sc)

(setf *s* (make-external-server "localhost" :port 48800))
(server-boot *s*)

(defvar *synth*)
(setf *synth* (play( sin-osc.ar [320 321] 0 0.2))) 
(free *synth*)

(server-quit *s*)
(server-query-all-nodes)

This, however, breaks tree-sitter (issue: https://github.com/tree-sitter-grammars/tree-sitter-commonlisp/issues/27)

Replacing the square brackets with parens makes tree-sitter happy, but then no code compiles... Also, when searching for common lisp and square brackets I find no mention of them anywhere. Is this some kind of non-standard implementation specifically created for cl-collider?

[defaultxr]

Hello and welcome to the world of Common Lisp :)

[1 2 3] is basically syntax sugar for (list 1 2 3). Simply replacing [ and ] with ( and ) won't be enough as then Lisp will expect that you are calling a function rather than creating a list.

The square brackets are indeed reader macros defined by cl-collider and are not a standard part of Common Lisp. They can be enabled using (named-readtables:in-readtable :sc), but they are optional and are not required if they break syntax highlighting/parsing in your environment.

In my experience they also seem to confuse SLY/SLIME as well, so I personally do not use them. I don't use tree-sitter for Lisp, and don't have a lot of experience with tree-sitter in general yet, so I'm not sure if it's possible to easily (re)configure it to recognize/parse them correctly. If you figure out a solution, please do share, as I'm sure there are users who would find that information helpful!

[kflak]

Ah, great to know! Seems like the simplest solution for now is just to avoid square brackets and use the (list 1 2 3) syntax instead.

I'm a heavy user of tree-sitter in neovim, so I'd love for it to work in cl as well as everywhere else :-)

[kflak]

Oh, and let's see what the deal is with the issue over at tree-sitter-commonlisp. I suspect that this might be a bit tricky if it's purely a cl-collider macro...

[defaultxr]

Ah, I see your issue there (which you also mentioned in your initial post on this issue). I'm not sure they'd be interested in adding support for custom reader macros that are specific to this project, especially since other projects may set [ and ] to have entirely different meanings.

The ideal solution would probably be for tree-sitter-commonlisp to be able to automatically pick up the current *readtable* and reconfigure its parsing based on that. But I'm not sure if tree-sitter supports such a thing--from what I understand, it's mainly designed for parsing static syntaxes, and might not support handling redefinable syntaxes. I could be entirely wrong about that though, and maybe it is possible. I don't imagine it would be too easy though.

[kflak]

Makes sense. I'm already happy that I am able to get the thing up and running using standard, static syntax :-)

BTW: is there some kind of forum/group somewhere for cl-collider? I will most likely have a bunch of questions soon that aren't very suitable for github issues...

[defaultxr]

Glad to hear it's working well for you now! :)

I don't think there is an official cl-collider forum/chatroom or similar. I idle on the #cl-collider channel on libera.chat (IRC) just in case anyone drops by, but I haven't noticed any actual chatter there yet (and I think IRC has fallen a bit out of favor in general, sadly).

I'm not sure but maybe @byulparan would be willing to enable GitHub's discussions feature for this repo to allow users to share patches/sequences/Q&A/etc. It seems like it could be a good option in this case, and I'd be willing to help in the discussions if needed.

[byulparan]

Ye~ I will turnon discussions feature soon!

[kflak]

Great! Looking forward to it :-) Closing the issue now with this.