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

Why are refs metadata rather than tags? #17

Closed
weavejester opened this issue Jun 3, 2016 · 10 comments
Closed

Why are refs metadata rather than tags? #17

weavejester opened this issue Jun 3, 2016 · 10 comments

Comments

@weavejester
Copy link

I'm curious why refs are metadata, and everything else uses tags. Is there a reason for this?

@malcolmsparks
Copy link
Contributor

EDN tag literals are like macros and great for immediate read-time
evaluation but you. Refs are (potentially) something you want to process
prior to them being elided by the reader. That's the primary rationale.
It's not set in stone.

I'm curious why refs are metadata, and everything else uses tags. Is there
a reason for this?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17, or mute the thread
https://github.com/notifications/unsubscribe/AAJ9O7U4IOP9DNqYGXDITLjyaB7J0_glks5qIHdUgaJpZM4Itzgc
.

@malcolmsparks
Copy link
Contributor

On my phone. Will fix up when back at a kb sorry!

@weavejester
Copy link
Author

Ah, that makes a lot of sense! Thanks for the quick response.

Still, metadata is data about data, whereas a tag alters the meaning or "type" of the data. Given this, would #ref [:foo :bar] be semantically better than ^:ref [:foo :bar]?

@gardnervickers
Copy link
Contributor

@weavejester I tend to agree that it should be a tag instead of metadata, however the implementation needs to still set a metadata flag on the returned value and be processed by walking down the tree and calling get-in on the partially resolved tree. We need to do this because there's not really a way to "walk back up the tree" to follow a path back down during read-time.

@weavejester
Copy link
Author

weavejester commented Jun 7, 2016

I was thinking that you could just create a "ref" placeholder type, and then walk the tree afterwards.

For example:

(defrecord Ref [keys])

(defmethod reader 'ref [_ _ value]
  (->Ref value))

(defn resolve-refs [config]
  (walk/postwalk #(if (instance? Ref %) (get-in config (:keys %)) %) config))

@malcolmsparks
Copy link
Contributor

I agree that ref metadata feels wrong now. Let's reconsider it and test an alternative approach prior to 1.0 final. I definitely not married to the ^:ref syntax and it feels a little inconsistent.

@SevereOverfl0w
Copy link
Contributor

This can now be considered done I think. #ref now works.

@xiongtx
Copy link

xiongtx commented May 12, 2017

README should be updated with #ref.

@timgilbert
Copy link
Contributor

#45 updates the README.

@malcolmsparks
Copy link
Contributor

This has been implemented. They are now tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants