Fork me on GitHub
#clojure-dev
<
2017-05-21
>
andy.fingerhut17:05:21

Perhaps the problem for which the solution is "add #clojure/var reader support" is obvious to most others, but is it described anywhere?

richiardiandrea18:05:01

Yep I am with above ☝️ , in particular, why this kind of serialization is needed as part of the reader, maybe I am missing some useful use case here 😀

Alex Miller (Clojure team)20:05:44

As an example, consider a configuration file that contains a reference to a function that does some kind of initializatipn. Right now you'd probably save a symbol, and then have some code on the read side that resolved the symbol. With var tag support you could just serialize the var, and on read it will be a runnable thing.

bronsa20:05:16

would (read-string "#var clojure.core/+) return (var c.c/+) or #'c.c/+ (as in, the var object)?

bronsa20:05:07

i'm assuming the latter to avoid the need for eval but then that means that printing vars using that tagged literal could be a breaking change

Alex Miller (Clojure team)23:05:39

The var - why would that be breaking?

Alex Miller (Clojure team)23:05:10

The tag will be #clojure/var btw

Alex Miller (Clojure team)23:05:06

For the printing options, this is the root of the request for comment in the clojure-dev mailing list

bronsa23:05:50

it would be breaking if what prints now as #'foo changed to #clojure/var foo, as reading it back would change from reading (var foo) to reading a var object

bronsa23:05:16

if the scope is just changing what now prints as #=(var foo) then that won't be breaking

bronsa23:05:27

i'll leave a comment on the ml tomorrow