rewrite-clj

https://github.com/clj-commons/rewrite-clj
2020-08-29T09:04:30.113800Z

the summary has been updated to include other bits -- including an edited version of lread's recent conversation with alexmiller

lread 2020-08-29T13:51:27.113900Z

I feel that the discussion is relevant to the channel. πŸ™‚ Unless working on the individual parts of speech, maybe only the phrase, or the result of interpreting the phrase are important? In was just trying to figure out what to call :: in the context of an auto-resolved namespace map. Clojure docs don’t seem to explicitly give :: a name in itself. I see that parcera calls it https://github.com/carocad/parcera/blob/1c513564fa6549fef7d39477b8bc359380f1942e/src/Clojure.g4#L126.

2020-08-29T14:59:58.114200Z

i ended up choosing to call that auto_resolve_marker. i also considered auto_resolve_mark. i think "sigil" is a term i've heard in at least the perl community, but wasn't so sure of its appropriateness, so opted against auto_resolve_sigil. auto_resolve_symbol also seemed like it might be confusing.

2020-08-29T15:51:27.114400Z

on a (sorry, long so feel free to skip πŸ™‚ ) side note, my current impression is that the situation parcera is in differs from tree-sitter's in at least one important way. the current parcera implementation uses antlr and then arranges for hiccup output based on that as a kind of multi-stage process (https://github.com/carocad/parcera/blob/1c513564fa6549fef7d39477b8bc359380f1942e/src/clojure/parcera/core.cljc#L69-L70). consequently, it has the option of changing the names of things in the antlr result to hiccup transition. more concretely, Clojure.g4's names (the antlr ones) in a way don't matter so much (to the user of the hiccup result) because there is an option of changing them during the "translation" to hiccup. (although that would probably reduce performance somewhat so may be one wouldn't want to.) unfortunately for the tree-sitter case, afaiu, once one decides on names within grammar.js (the typical tree-sitter grammar file), one is in a way stuck with those names -- those names show up in the parse tree which a consumer has access to (so one might think of the names as being part of a public api). the reason this is relevant is that within parcera's Clojure.g4 file, one can choose names that make sense "in-context". for example, here: https://github.com/carocad/parcera/blob/1c513564fa6549fef7d39477b8bc359380f1942e/src/Clojure.g4#L110 one can see the name var_quote. that name is within the context of dispatch which is in turn in the context reader_macro. so if one has the grammar's structure in mind, the name is not too confusing. however, for the tree-sitter case, if one were to choose that kind of name, all you get as an end-user from the parse tree is var_quote (which might suggest #'), which is less clear than var_quote_form outside of the context of a grammar file (which is the case when all you have is the parse tree). the issue is somewhat compounded by the total number of names of things in the grammar (each pair of terms being the potential source of confusion) in addition to some terminological gaps and confusion (which afaict are partly inherited from lisp communities). atm, for tree-sitter i am trying to choose names that can stand on their own (when compared to each of the other names) to ease learning and reduce confusion when reasoning for the user of the parse tree (editor-tooling folks being one prime target). thus a name like "form" would likely invite confusion if used to describe something specific to tagged literals or metadata in a tree-sitter parse tree. come to think of it, many of the other tree-sitter grammars i've looked at do tend to use rather long specific names...perhaps the aforementioned reasoning went into such decisions in some of those cases. so if you made it this far, i hope that explanation made it a bit clearer where i'm coming from πŸ˜…

lread 2020-08-29T18:55:17.115700Z

I found that interesting, thanks for sharing!