@lee btw, i've recently started to wonder a bit whether the way metadata is done currently in rewrite-clj* could be better in some cases compared to what some of us mentioned some time back (about the idea of the metadata node not wrapping the stuff that the metadata applies to).
Hi @sogaiu! Do you mean this discussion? https://github.com/lread/rewrite-cljc-playground/issues/2 I’m interested to hear about your new ideas.
@lee yes, that's the discussion -- thanks for the reminder! here are 3 alternative approaches as i understand things: 1) metadata wraps the things it applies to (rewrite-clj* and parcea do this i think) 2) metadata is treated as a completely separate entity 3) borkdude's idea -- lol, i guess that looks similar to what i did before in tree-sitter-clojure i had just tried implementing 2) today and got to thinking that it can make things awkward if you want to figure out what the metadata applies to (e.g. what if there are comments or discard forms in between the metadata and what it is supposed to apply to). that's what got me thinking that there was something to option 1), but now that i've reviewed things, i guess i still like option 3 afterall 😅
me too ;)
but I can understand that this will be a major breaking change. however, since it's a new library that may be a better time to introduce a breaking change than any other
@sogaiu, I think it is great that you are exploring ideas and I thank you for sharing them!
the other major change I made to rewrite-clj is to skip over whitespace, #_
and ;;
comments
but that could be an option
if these two things were in a rewrite-clj* lib, I could at some point go back to a shared library
the metadata thing could also be an option
One of my primary goals with rewrite-cljc has been to maintain as much API compatibility as I reasonably can with rewrite-clj and rewrite-cljs.
which is a good start :)
Ya I think so too. 🙂
on a somewhat related note, i've been thinking that discard, tag, and metadata seem to have some kind of structural similarity
yes
whatever approach is chosen for one might be worth considering for the others
I guess you can also have multiple readers:
user=> (set! *data-readers* {'foo identity})
{foo #object[clojure.core$identity 0x303a5119 "clojure.core$identity@303a5119"]}
user=> #foo #foo 1
1
Never knew that, but cooli didn't know until i started testing heavily 🙂
you can do some really odd things
I'm not sure if storing the data reader as a child makes sense though, it's more similar to a function call
(foo (foo 1))
i'm not sure either, which is why i wrote it as "might be worth considering" 🙂
ok
just wanted to throw it out for general consideration
btw, i ported parcera's grammar to tree-sitter today
wow... nice
it seems like a much cleaner break-down than what i came up with
so i may switch to it after more testing (that is, using it as a basis for a grammar in tree-sitter)
(i also ported it to janet 😉 )
actually, i ported a fair bit of parcera to janet
Cool! I listed parcera as an interesting alternative to rewrite-cljc in rewrite-cljc docs.
It currently is the only thing in the list, are there others?
edamame also plays in this area, it's not whitespace preserving, parses directly to sexprs, but like rewrite-clj it has location metadata on each thing
those are the 3 that come to mind atm (at least things that are relatively current)
Thanks, I’ll add edamame to the list!
I recently added an option to edamame that allows you to preserve location metadata of non-metadata-carrying objects like numbers, by wrapping them. It only occurs to me now that using that new feature I could have maybe used it in clj-kondo for linting... hmmmm
not that I will go down that path, but if I would write it from scratch, that could've been an option
hmmmm indeed!
oh yes, now I remember why rewrite-clj is better here: it allows you to keep on processing even if a map is not formatted correctly. e.g.:
{:a}
(inc "foo")
Although the first map is not parseable, you will still get a warning for the second thingso the choice for rewrite-clj is still valid today
I should make sure I have explicit tests for that
To ensure behavior is preserved moving forward
I guess edamame could have a mode where it would just kept on parsing even if the current thing was invalid
like (defrecord InvalidNode [...])
the "keep on parsing" idea sounds vaguely familiar
Is this irony/sarcasm or not? I can't tell from the absence of facial expressions or emoticons
this is not sarcasm -- merely recollection that is incomplete 🙂
hmm, clojurians-log is unavailable atm
I thought you maybe meant that tree-sitter does keep on parsing :)
ya @sogaiu, I remember you playing with a fork of rewrite-clj that could keep on parsing in the face of invalid clojure...
@lee ah, right -- this thing: https://github.com/sogaiu/rewrite-cljs-playground/commit/7074cfc222aa65c93020bddeed83c0236e4f86b8
ah bed time for me -- good to chat with y'all 🙂
g’night!
g'night!