This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-11
Channels
- # babashka (3)
- # beginners (70)
- # calva (15)
- # cider (34)
- # clara (10)
- # cljsrn (2)
- # clojure (28)
- # clojure-europe (21)
- # clojure-france (1)
- # clojure-uk (17)
- # clojuredesign-podcast (4)
- # clojurescript (51)
- # cursive (21)
- # data-science (1)
- # datalog (2)
- # datascript (2)
- # datomic (10)
- # emacs (5)
- # esprit (24)
- # expound (9)
- # figwheel-main (15)
- # fulcro (31)
- # graphql (3)
- # jobs-discuss (27)
- # keechma (2)
- # luminus (2)
- # malli (2)
- # minimallist (14)
- # nrepl (1)
- # off-topic (4)
- # pathom (1)
- # pedestal (8)
- # re-frame (10)
- # reagent (5)
- # reitit (2)
- # rewrite-clj (54)
- # sci (1)
- # shadow-cljs (34)
- # spacemacs (12)
- # sql (17)
- # vim (16)
- # web-security (1)
@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 😅
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
if these two things were in a rewrite-clj* lib, I could at some point go back to a shared library
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.
on a somewhat related note, i've been thinking that discard, tag, and metadata seem to have some kind of structural similarity
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'm not sure if storing the data reader as a child makes sense though, it's more similar to a function call
so i may switch to it after more testing (that is, using it as a basis for a grammar in tree-sitter)
Cool! I listed parcera as an interesting alternative to rewrite-cljc in rewrite-cljc docs.
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
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
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 thingI guess edamame could have a mode where it would just kept on parsing even if the current thing was invalid
Is this irony/sarcasm or not? I can't tell from the absence of facial expressions or emoticons
ya @sogaiu, I remember you playing with a fork of rewrite-clj that could keep on parsing in the face of invalid clojure...