Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review map-node vs namespaced-map-node #131

Open
lread opened this issue Feb 20, 2021 · 3 comments
Open

Review map-node vs namespaced-map-node #131

lread opened this issue Feb 20, 2021 · 3 comments
Labels
hammock requires some thought

Comments

@lread
Copy link
Collaborator

lread commented Feb 20, 2021

Moved from TODO note in docs in user guide.

Our map-node and namespaced-map-node model the structure of the source code.
This is convenient when navigating through nodes as one would through source.

But... when we want to logically treat any map as a map the difference is a bit awkward.

I was thinking a protocol for map nodes, but this would only be useful for the non-zipper (direct node) user:

  • (get-map-children n)
  • (replace-map-children n)?

So... not sure what might help.
In a previous experiment, I modeled all maps the same, but this made dealing the space that can occur after the namespaced map prefix inconsistent with the rest of the whitespace treatment in rewrite-clj.

@lread lread added the hammock requires some thought label Feb 20, 2021
@lread
Copy link
Collaborator Author

lread commented Mar 4, 2021

To remain compatible with rewrite-clj v0, we'll need to keep node layout the same.
Anything that we might invent to help treat all maps as maps can be added later.
So I can move this issue to a lower priority for now.

@borkdude
Copy link
Collaborator

borkdude commented Jan 6, 2022

Another idea: make tag+ return namespaced keywords which can be used to build a hierarchy.

(isa? :rewrite-clj/string :rewrite-clj/token) ;;=> true

@lread
Copy link
Collaborator Author

lread commented Jan 6, 2022

Thanks for the new idea @borkdude!

For the uninitiated (and/or foggy-brained), in Clojure, we can define hierarchies via derive.

user=> (isa? :rewrite-clj/string :rewrite-clj/token)
false
user=> (derive :rewrite-clj/string :rewrite-clj/token)
nil
user=> (isa? :rewrite-clj/string :rewrite-clj/token)
true

So rewrite-clj would provide finer-grained type information via a new tag+ (see #114) but also define a queryable hierarchy for that new type info via Clojure's isa?.

Why do the keywords that are returned by tag+ need to be qualified with :rewrite-clj? Because we'd be registering their relationship via Clojure's derive whose registry is global and therefore we need the qualifier.

An alternative might be to use Clojure's make-hierarchy to create a rewrite-clj specific hierarchy, but then usage might be more awkward.

@lread lread added this to rewrite-clj Jul 3, 2024
@lread lread moved this to Low Priority in rewrite-clj Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hammock requires some thought
Projects
Status: Low Priority
Development

No branches or pull requests

2 participants