Clojurians Log v2

Yeah, good point. About those read-string variants, I guess if the caller wants, they can then eval the read-string expression? You might assume I should know, but as I don’t have access to the original author of rewrite-clj, I make guesses, and ponder with others in this channel. :man-shrugging:

@dave.dixon I forgot I had raised an issue to document read-string returns. Added your example. https://github.com/lread/rewrite-cljc-playground/issues/53

As for the original discussion about losing namespaced map context when sexpr-ing on an individual key in the map… There might be something I can do, but I think I’ll just raise a git issue to maybe (or maybe not) address later… and document the limitation. @borkdude would this work for you too?

@lee I'm not sure what to do here. I think supporting this will maybe complicate things since the nodes are no longer context-free?

An alternative might be to make the keys namespaced as well and store the namespaced map as such

@lee I think that may not be a bad idea. I'm not sure what the consequences are for restoring the code to string from such a change

The issue is only for sepxr. So kind of a special case. Are you suggesting the keyword would optionally also carry the namespaced map prefix and auto-resolved? values?

The zipper is aware of the tree and knows the parent. I suppose it could optionally pass in the parent node info when sexpr ing a keyword-node that is in a namespaced map. But that might be a bit gross.

Alternatively the parser could add the namespaced map context to the keyword node. But then we’d have that same data in two places, perhaps making node update confusing.

@lee I was suggesting that the keyword node would just be literally :foo/bar represented as a normal rewrite-clj keyword

sexpr-ing that would then automatically work

and also these nodes are more consistent to look at outside the context of the map

How would that work for folks who just want to reformat source code?

#::myalias  {:x 1 :y 2}

@lee I think this would actually simplify things. What if you would add an un-namespaced key? Then you would have to print the map differently anyways. So when printing a namespaced map, one should check if the map is still namespaced and if all the children are still namespaced accordingly.

I’m not following… yet! :simple_smile: A tool like cljfmt only wants whitespace affected. Non-whitespace code remains as written by the author. If the author wrote:

#:booya {:x 1 :booya/y 2}

#:booya{:x 1 :y 2}

I understand that this is the case for cljfmt, but not for refactoring tools

e.g. the editor that @dave.dixon is going to make, might manipulate keys of a map

This seems no different than editing clojure code. If you had the map #::myalias {:x 1 :y 2} and wanted to add un-namespaced :z, you'd have to edit the code to be {::myalias/x 1 :myalias/y 2 :z 3}. Those two things should parse to different AST's. How about a function to transform between the two AST node types?

@dave.dixon I'm talking about the case where you first parse the first example, then manipulate the keys code-wise and then write out the map. I'm not even sure if that works correctly today.

So if you store the keys always in a normalized fashion, you don't have to bother looking at the properties of the parent map. The printing of keys should always work independently from the parent map. And when printing the parent map, one can do a simple check: 1) the map was namespaced and 2) the children are all still namepaced, then write the prefix form, else write a normal map with individual keys

So, would rewrite-cljc rewrite this:

{:foo/x 1 :foo/y 2}

#:foo{:x 1, :y 2}

no, because the parent map of the keys is not namespaced

you would only write the second if the original map node was already namespaced

(-> (z/of-string "#:foo{:doink 1}")
     z/down
     z/right
     (z/append-child (n/keyword-node :bar))
     (z/append-child (n/value 2))
     (z/print-root))
=>
#:foo{:doink 1 :bar 1}

yeah, that's wrong

also getting the key :doink from the children and calling sexpr on it would be wrong right now

It's wrong in the sense of how the Clojure compiler would interpret it, right in the sense of being a literal translation of what was typed. For example, the clojure compiler would not accept the form ` ` (p/parse-string "{:foo 1 :bar}")

sexpr should return not what is typed, but what is semantically the correct representation in clojure

to return what is typed you can already use str

Yes, I agree that sexpr should handle things differently. And in general, it may be useful to have functions that transform nodes from a literal representation of the text to something closer to what the compiler actually sees after the reader does its thing. sexpr could probably leverage that to be more consistent.

Does (sexpr namespaced-map) give the right result right now?

Sorry, had to run an errand… This is a great discussion, thanks to you both! Forgetting about sexpr or a moment, I think it is important that what rewrite-cljc writes out what was written by the original author of the parsed code (with the exception of newlines which might be converted). I don’t mean semantically equivalent, I mean what the author typed in at the keyboard. This should, ideally, return true for any source we throw at rewrite-cljc:

(def source (slurp "<https://raw.githubusercontent.com/borkdude/clj-kondo/master/src/pod/borkdude/clj_kondo.clj>"))
(= source (-&gt; source z/of-string z/root-string))

Yes, it should work

Cool, thanks @borkdude, that helps me to understand your angle better. I’ll dig in and explore your idea more deeply.

@borkdude, with your idea, would this rewrite as it was written?

#:foo {:x 1 :foo/y 2}

@lee that's an edge case I haven't thought about. This is another edge case I didn't know was possible:

#:foo {:x 1 :bar/y 2}
{:foo/x 1, :bar/y 2}

There’s a really good code snippit in https://clojure.atlassian.net/browse/CLJ-1910 that describes namespaced map behaviours.

Until I read its examples, I did not know about the _ prefix:

;; effects on keywords with ns, without ns, with _ ns, and non-kw
user=> #:foo{:kw 1, :n/kw 2, :_/bare 3, 0 4}
{:foo/kw 1, :n/kw 2, :bare 3, 0 4}

afk for a bit…

Huh... wow

that seems like a major hack ;)

@lee I'm happy to learn edamame parses this correctly:

user=> (e/parse-string "#:foo{:kw 1, :_/bar 3}")
{:bar 3, :foo/kw 1}

Ha! I guess it is not a horrible way to support unqualified keys in a namespaced map?

Just probably not well known

I don't think namespaced maps are really that widely used anyways

Ya, https://grep.app/search?q=%23%3A%2B%5Ba-z%5D%2A&regexp=true&filter[lang][0]=Clojure.

Anyhoo, I’ll sleep on all this and take a look again tomorrow. If nothing obvious and good comes to mind, I’ll just defer the work to a git issue.

Just so I can get some momentum of some sort! :simple_smile:

Most of those hits seem to show either tests for clojure itself or related tooling, or Datomic-related stuff

Have a good night