"tagged form" sounds like a good candidate.

on a side note, any ideas about a similar thing for metadata? as in, what's the thing the metadata is supposed to apply to?

It’s tricky, huh? If I look a Clojure docs on the subject https://clojure.org/reference/metadata, it seems “metadata” is clear, but the thing it is describing has multiple terms. “Object” is used in descriptive text and APIs, but “data” is also used in text and also an attractive choice. “Object” might be more telling as metadata cannot be applied to all things - but really, that might be describing an implementation detail. So I think I personally prefer “data”. As for what to call the “metadata” and “data” together, I don’t know if a term is needed for that.

yes it is tricky - i realize now that unless you are working on a grammar much of this may seem irrelevant. it turns out that for grammar work, depending on how things are decomposed, what you might want a name for is impacted. as an example from parcera's current grammar, consider: https://github.com/carocad/parcera/blob/master/src/Clojure.g4#L66 here the name is metadata, but it refers to the combination of one or more pieces of metadata and the thing it applies to. in one of my tree-sitter grammar attempts, i tried to have the metadata bits live "inside" the thing it applies to and consequently (atm) don't have a need for the combined term for the tree-sitter grammar. however, if it turns out that's too slow or there is a need to change the grammar for another reason, i might need such a name. does that make sense? another place where the necessity for such names may surface is in the ui of editors - imagine an option for choosing highlighting or styling of specific portions of code (e.g. display what the discard #_ macro reader marker(?) applies to, or dim the metadata annotations(?) but not the thing it applies to, etc.) fwiw, with tree-sitter support in some editors coming about, these are not far-fetched possibilities. in any case, i appreciate the input and feeback i have received so far but perhaps this channel is not the best place to discuss this.

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.

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.

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 😅

I found that interesting, thanks for sharing!

thanks for tolerating these emissions 🙂 btw, i am still trying to understand better your recent remark: > Unless working on the individual parts of speech, maybe only the phrase, or the result of interpreting the phrase are important? would you mind elaborating on that at some point? possibly with an example?

I guess I might have been getting a bit philosophical. 🙂 I simply meant that the Clojure core team didn’t really need to give a specific name to :: (a part of speech) when they were describing, for example, auto-resolved current namespace maps ::{:a 2} (a phrase).

ah, thanks for the explanation. that specific thing is interesting because it seems to be indirectly referred to on the reference page for the reader: > Symbols beginning or ending with ':' are reserved by Clojure. A symbol can contain one or more non-repeating ':'s. https://clojure.org/reference/reader#_reader_forms

i am guessing, but it seems to me that constraint might be partly due to trying to avoid a collision with the use of :: for auto-resolving. if one were physically speaking about this, it might be easier to discuss if :: had a name. perhaps "double colon" might be something that might get used if one were speaking, but if you type "double colon" it really doesn't seem to have a whole lot of benefit over ::. so i wonder if the medium of typical discussion about these things (and for that matter, the number of people who might actually converse about it) might affect whether something gets a name and further the type of name something might get. in typical grammars (e.g. for antlr or tree-sitter), there are constraints about what you can name things (e.g. restricted characters) -- typically similar to those in programs so perhaps you tend to end up with words (i.e. :: wouldn't be a valid name).

Yep, good points. My first crack at supporting namespaced maps uses the illegal Clojure symbol ::. My next version won’t do that.

he he 🙂

btw, thanks to recent discussions here plus investigations, i realized i wasn't really clearly aware of this: https://clojure.org/reference/reader#_deftype_defrecord_and_constructor_calls_version_1_3_and_later it looks like they can be recognized just like tagged-literals. indeed tagged literals and these things both seem to be handled by CtorReader in LispReader.java. most grammars i've seen refer to tagged literals (or tags) with no apparent mention of this other thing. i have been using tagged_literal (or something involving tag) as a name for the construct, but wonder whether i should somehow sneak in ctor. fwiw, there was some discussion about this here: https://github.com/carocad/parcera/issues/83

hmmm... thanks! I’ll have to check if/how rewrite-clj handles this.

btw, when i looked at the official docs, it wasn't clear to me where spaces, discards, comments and such could go. i did some experimentation and my current conclusion is that it's the same as tagged literals. here's a small repl session snippet:

user=> (defrecord Fun [a b])

user=> #  [1 2]
#{:a 1, :b 2}

re: names used in speech -- happened to be watching this rh talk and heard him refer to #= as "sharp equals" around here: https://youtu.be/I5iNUtrYQSM?t=3734