Printing aliased keywords

[Sam Estep]

The syntax for namespaced maps was added to make working with namespaced keywords easier. However, while the combination of namespace aliases and namespaced maps allows concise source code, all namespaces are fully expanded in REPL output. To address this readability problem, I propose a *print-alias* dynamic var that, when set to a truthy value, causes pr to make use of (ns-aliases *ns*):

(set! *print-alias* true)
;;=> true

(require '[clojure.repl :refer [doc]]
         '[clojure.spec :as s])
;;=> nil

(s/def ::some some?)
;;=> ::some

(doc ::some)
;; -------------------------
;; ::some
;; Spec
;;   some?
;;=> nil

(s/conform ::some nil)
;;=> ::s/invalid

(s/explain-str ::some nil)
;;=> "val: nil fails spec: ::some predicate: some?\n"

(s/explain-data some? nil)
;;=> #::s{:problems [{:path [], :pred some?, :val nil, :via [::some], :in []}]}

I already have a working print-method for clojure.lang.Keyword; if it’s OK with everyone, I’ll finish modifying the print-method for clojure.lang.IPersistentMap and submit a patch to JIRA.

​

[Kevin Downey]

On 08/11/2016 11:11 AM, Sam Estep wrote:
> The syntax for namespaced maps

> <https://groups.google.com/forum/#!topic/clojure-dev/8tHLCm8LpyU> was

This seems like a bad idea. Namespaced maps are self descriptive because
they include the namespace context with them. An aliased keyword like
::s/foo does not come with the information required to resolve the s
namespace, and relies on state in the runtime, which differs.

I've seen bugs with aliases like ::s/foo in code where code was moved
between namespaces, the alias resolves different, and suddenly things
don't work. Given that there is generally way more data in most systems
than there is code, once you start doing the alias thing in data instead
of code you are going to see a lot more of this kind of problem.

This is only going to do anything at the repl, which is sort of a mix of
compile time and runtime. *ns* is really a bit of compilation state,
which at runtime of any function can have any particular value. In most
clojure systsems I have worked on at any particular moment, if a running
function looked at *ns* the value would be the clojure.core namespace,
because that is the default value it has when you aren't compiling
something.

Given that this is really only useful at the repl, I would suggest that
if you want to do it, you leave it out of the general printing system,
that is often used outside of the repl. You could add something like it
by creating your own repl with a special printing function, or writing
some kind of nrepl middleware.
​
>
> --
> 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
> <mailto:clojure-dev...@googlegroups.com>.
> To post to this group, send email to cloju...@googlegroups.com
> <mailto:cloju...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/clojure-dev.
> For more options, visit https://groups.google.com/d/optout.


--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

[Alex Miller]

My reaction to this is mostly the same as Kevin's. I don't think it's something we'd generally want, but it might be a useful repl printing mod, but that's probably not something we'd include in Clojure itself.

> an email to clojure-dev+unsubscribe@googlegroups.com
> <mailto:clojure-dev+unsub...@googlegroups.com>.

> To post to this group, send email to cloju...@googlegroups.com

> <mailto:clojure-dev@googlegroups.com>.

> Visit this group at https://groups.google.com/group/clojure-dev.
> For more options, visit https://groups.google.com/d/optout.


--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

--
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.
To post to this group, send email to cloju...@googlegroups.com.

[Sam Estep]

I agree that the loss of information incurred by printing aliases is undesirable; that’s why I was proposing that *print-alias* be set to false by default. However, I’ll defer to your judgment about whether or not this should be in core Clojure.

> an email to clojure-dev...@googlegroups.com

> <mailto:clojure-dev+unsub...@googlegroups.com>.
> To post to this group, send email to cloju...@googlegroups.com

> <mailto:cloju...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/clojure-dev.
> For more options, visit https://groups.google.com/d/optout.


--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

--
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.

​