RFC: var printing

255 weergaven
Naar het eerste ongelezen bericht

Alex Miller

ongelezen,
19 mei 2017, 11:36:0419-05-2017
aan Clojure Dev
Currently one can't send vars around in edn. #' is clojure reader specific. 'variable' may or may not be general enough to justify #var in edn, else #clojure/var could work. Objective is just to transmit var identity and bind to same-named var on reading side (a la var serialization support). Printing would need to prn #var instead of #' (perhaps via a flag), and edn/read tables for Clojure need to include var reading


Currently one can't send vars around in edn. We are working on adding the capability to transmit var identity and bind to the same-named var on the reading side. Rich made some changes recently (they are in 1.9.0-alpha16) for doing this in Var with Java serialization. Additionally, we are currently working on adding a var tagged literal for the same purpose. This would not be part of edn as vars may not have meaningful semantics in other languages, but rather a tagged literal specific to Clojure. The format will look like:

  #clojure/var clojure.core/conj

The read side of this is pretty straightforward. The area where we are seeking more feedback is in printing. Currently vars print in one of two ways:

  #'clojure.core/conj  - seen in most cases 
  #=(var clojure.core/conj) - when printed with *print-dup* true (probably almost no one ever sees this)

The question is what the print format should be in various contexts:

1) with print-dup - switch to #clojure/var (preferable to using read eval)
2) without print-dup, in the REPL - ??? 
3) without print-dup, outside the REPL - ???
4) other context I'm not thinking of

The existing #' reader macro will of course remain so the read-side changes are purely additive. Is anyone relying on the #' printing for things that would not be satisfied by #clojure/var? Obviously the new format is more verbose and thus it might be preferable to print the #' form in the REPL.

Thanks.






Nicola Mometto

ongelezen,
22 mei 2017, 04:43:0922-05-2017
aan cloju...@googlegroups.com
As mentioned on slack, I believe that changing the behaviour of the default print-method would be a breaking change, so my vote would be to just change the print-dup printing.

Example of what the difference would be:
Currently, pr-str+read-string on a var return a list of var + the var name
user=> #'+
#'clojure.core/+
user=> (-> #'+ pr-str read-string)
(var clojure.core/+)


Changing the default printing to use a tagged reader that resolves the var, would make pr-str+read-string on a var return the var object
user=> (defmethod print-method clojure.lang.Var [o ^java.io.Writer w] (.write w (str "#var " (-> o .ns .name) "/" (.sym o))))
#object[clojure.lang.MultiFn 0x32a1bec0 "clojure.lang.MultiFn@32a1bec0"]
user=> #'+
#var clojure.core/+
user=> (binding [*data-readers* {'var resolve}] (read-string (pr-str #'+)))
#var clojure.core/+


--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.

signature.asc

Alex Miller

ongelezen,
22 mei 2017, 10:03:3422-05-2017
aan Clojure Dev
I've added a ticket with a first cut patch for this at https://dev.clojure.org/jira/browse/CLJ-2165 if it helps to play with it.

In the patch, print-dup of vars print as #clojure/var and existing printing of vars as #' is otherwise retained, but there is a new flag *print-var-tag* that lets you decide whether to print as #clojure/var instead. All still subject to change.

Daniel Compton

ongelezen,
22 mei 2017, 18:34:1322-05-2017
aan Clojure Dev
This is slightly more to do with var serialisation in EDN, but how (if at all?) would ClojureScript handle var serialisation? Would it use #clojurescript/var? Would ClojureScript also read #clojure/var and translate the namespaces as it currently does with cljs.* -> clojure.* namespaces?

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
--

Daniel

Alex Miller

ongelezen,
22 mei 2017, 19:25:4922-05-2017
aan Clojure Dev
The main use case we were thinking about was Clojure to Clojure. It doesn't make sense to use a different tag in ClojureScript if your goal is interop (so read clojure here in the broad sense). I'm not sure it would be useful in cljs without reigned vars?

Nahuel Greco

ongelezen,
22 mei 2017, 20:45:3522-05-2017
aan cloju...@googlegroups.com
just curious, what are the use cases you are thinking for this feature?

Saludos,
Nahuel Greco.

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscribe@googlegroups.com.

Alex Miller

ongelezen,
23 mei 2017, 09:30:0923-05-2017
aan Clojure Dev

On Monday, May 22, 2017 at 7:45:35 PM UTC-5, Nahuel Greco wrote:
just curious, what are the use cases you are thinking for this feature?

Any case where you want to send function references around in edn and reconnect them to vars on the other side. Someone mentioned that Onyx has some things like this in their configuration where keywords map to functions - var tags would be an alternative in that case.
Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten