This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-18
Channels
- # 100-days-of-code (6)
- # announcements (4)
- # beginners (126)
- # cider (49)
- # cljdoc (28)
- # cljsrn (3)
- # clojure (89)
- # clojure-dev (19)
- # clojure-greece (2)
- # clojure-italy (13)
- # clojure-mexico (1)
- # clojure-nl (13)
- # clojure-spec (108)
- # clojure-sweden (1)
- # clojure-uk (48)
- # clojurescript (31)
- # cloverage (3)
- # core-async (16)
- # cursive (28)
- # data-science (3)
- # datascript (1)
- # datomic (60)
- # defnpodcast (1)
- # docker (17)
- # editors (18)
- # emacs (16)
- # events (1)
- # figwheel (22)
- # figwheel-main (4)
- # graphql (26)
- # jobs (2)
- # off-topic (9)
- # om-next (2)
- # overtone (4)
- # perun (1)
- # re-frame (2)
- # reagent (18)
- # reitit (1)
- # ring-swagger (2)
- # shadow-cljs (2)
- # tools-deps (49)
- # uncomplicate (1)
- # unrepl (1)
- # vim (2)
“doesn’t work” == ?
i was getting compiler errors and it was mostly unrelated (missing spec definition further up the chain)
:foo/1
won't read; using a bare number as the name part in a keyword literal is a bad idea
that it works at all is an historical accident, and it wasn't fixed because it was noticed too late
hm, i have to digest this because it’s not making sense. are you saying that ::1
ultimately just becomes my.namespace/1
and thus {1 true}
?
I am saying clojure does not have a strict formal grammar for keywords and symbols, only human descriptions and implementations; using numbers is a greyer, edgier case that risks you falling into implementation-specific behavior
I think this is the heart of this particular reader ambiguity: https://dev.clojure.org/jira/browse/CLJS-677?focusedCommentId=35025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-35025
Clojure 1.9.0
user=> {::1 1}
#:user{:1 1}
user=> {:1 1}
{:1 1}
user=> #:user{:1 1}
#:user{:1 1}
user=> {:user/1 1}
RuntimeException Invalid token: :user/1 clojure.lang.Util.runtimeException (Util.java:221)
1
RuntimeException Unmatched delimiter: } clojure.lang.Util.runtimeException (Util.java:221)
well I’m a core member and I wrote that ticket and patch
the original intent was that keywords follow the same constraints as symbols
symbols cannot start with a leading digit
the regex for keywords is subtly incorrect and allows keywords to have a leading digit
by “fixing” that we discovered that people were using such things (at the time java.jdbc made result set keywords like that for example)
there did not seem to be any good reason to break people’s existing working code so we rolled that back
so it’s possible to read and use :1
and ::1
and we have no plans to make that stop working
I would say that’s never been resolved
CLJ-1527 is the ticket to do so
> Keywords - Keywords are like symbols, except: > They can and must begin with a colon, e.g. :fred. > They cannot contain '.' or name classes.
“resolving” means making that reference page and the code in sync
but the first question is what should be allowed
there are plenty of other open areas for characters that are allowed in the reader but not explicitly allowed in the reference docs
two things: 1) "are like symbols" seems to cause confusion about whether what follows includes or does not include the initial colons. that was what my comment in cljs-667. 2) keywords can't have '.'? even in the ns part? (I know putting them in the name part is discouraged because that looks like class names). That's definitely wrong?
keywords can definitely have dots in the namespace part
It says “or in namespace names” ?
"keywords are like symbols, except: They cannot contain '.' or name classes." is what it says now
oh, sorry I was looking at the symbol part
I’ll look at an edit to that, but the intent again is to be similar to symbols and allow dots in namespaces
agreed - the question is whether to describe two things as similar and then indicate differences or to restate, obscuring the differences
I don’t feel that there is any ambiguity in intent that keyword namespaces should allow .
specifically "Symbols begin with a non-numeric character" combined with "keywords are like symbols" causes one to wonder, "does a keyword begin with : or the char after that"?
well that is exactly the bug in the regex
but I would say after the colon
the intent of the spec being: "expand ::, chop off the first :, and you should have a valid symbol literal"
if you ask for the namespace and name parts of a keyword, you don’t see a colon. the colon is syntactical
I don’t think that’s a semantically meaningful operation, so I wouldn’t describe it that way
what I mean is the intuitive sense of a valid keyword was intended to be "does it look like a symbol if the colons that make it a keyword were removed"
I understand what you mean. I just wouldn’t describe it that way
I think that's a little better than "keywords are like symbols," but still inappropriate for a capital-S "specification"
https://github.com/clojure/clojure-site/commit/5481163d24491ec2ebc5863bc2d0876d36aacc5a
I’d say that’s not supported in either symbols or keywords. whether it reads is a separate question
expound question: I try to make a custom print function:
(alter-var-root #'s/*explain-out*
(expound/custom-printer
{:show-valid-values? false
:value-str-fn my-value-str
:print-specs? true}))
but I get:
Unhandled clojure.lang.ExceptionInfo
Unknown data:
{:data #function[clojure.spec.test.alpha/spec-checking-fn/fn--3026]}
what up?Just keep in mind that alter-var-root
will appear to not work if you are within a clojure REPL (you’ll want set!
in that case)
it appears that expound is working, but I don’t see my function being used in the output:
(alter-var-root #'s/*explain-out*
(constantly (expound/custom-printer
{:show-valid-values? false
:value-str-fn my-value-str
:print-specs? true
}) #_expound/printer)
)
@bbrinck in my custom function I want to say: if this is a com.stuartsierra component map, I want to print only the keys (else I’m flooded with pages of information), else I want to do whatever is the default in expound
@borkdude Hm, unfortunately it’s not super easy to do the else
part right now, but if you create an issue I’ll think more about how to make it nicer. Right now, I think the best you could do is to use the private function value-in-context
or grab the value of the private var *value-str-fn*
and call that. https://github.com/bhb/expound/blob/master/src/expound/alpha.cljc#L85
What’s the best way to make clojure.spec.alpha not print the entire component system map. We are using (s/assert ::system system). Even when making a custom expound printing function, clojure.spec still barfs my entire console with output.
I’m curious to know which part of the output is showing the entire map - I would think if you provide a custom printer, you could in principle hide it entirely (or show as much as you like), but maybe it’s printing somewhere else?
until line 124 it’s ok, there I only print the keys of the system map. afterwards, still the whole system is printed.
@borkdude Ah, right, so this isn’t actually spec - the issue is that the program is printing out all the exception data from the assertion
Is this running in boot? I wonder if the error printer is configurable? I can see why this is the default (you want to see the data for an assertion exception)
but in the context of spec, it will put all of the detailed explain-data
into the exception
I can see why that’s how boot works and I can see why spec adds a lot of info to the exception (might be useful), but when they work together, it’s definitely a lot of output.
I also tried this:
(try (rr/reset)
(catch Exception e
(throw (component/ex-without-components e))))
but that doesn’t work, because the assert exception already has the entire system in it :-s
hm, not sure what you mean. Why can’t you alter the exception data in ex-without-components
?
or just construct a new error that has less info, using the message from the exception
hmm, I have to inspect the exception in the REPL to see what to dissoc, but good idea
If that doesn’t work, the code for assert
isn’t too long, might be possible to just use a custom one: https://github.com/clojure/spec.alpha/blob/f23ea614b3cb658cff0044a027cacdd76831edcf/src/main/clojure/clojure/spec/alpha.clj#L1959-L1968
@bbrinck so what I wanted was actually not a custom :value-str-fn
function, but a way to transform my value before it’s printed by expound. would it make sense to have a :transform (fn [v] ...)
option in expound on the custom printer?