Fork me on GitHub
#clojure-spec
<
2018-10-18
>
alexmiller16:10:21

“doesn’t work” == ?

lwhorton16:10:11

disregard, being stupid again. 😞

lwhorton16:10:48

i was getting compiler errors and it was mostly unrelated (missing spec definition further up the chain)

favila16:10:20

:foo/1 won't read; using a bare number as the name part in a keyword literal is a bad idea

favila16:10:53

that it works at all is an historical accident, and it wasn't fixed because it was noticed too late

lwhorton16:10:09

is ::1 equally a bad idea?

favila16:10:17

yes, so is :1

favila16:10:01

think "would this be a readable symbol if I chopped off the initial :s?"

lwhorton16:10:30

well, isn’t {:1 true} a valid map?

favila16:10:45

I'm just talking about literals

lwhorton16:10:45

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}?

lwhorton16:10:30

:thumbsup: thanks

favila16:10:06

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

favila16:10:26

but that's just my opinion

favila16:10:44

no core member has confirmed or clarified to my knowledge

taylor16:10:06

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)

😂 4
favila16:10:25

I think this started it all

alexmiller16:10:04

well I’m a core member and I wrote that ticket and patch

alexmiller16:10:28

the original intent was that keywords follow the same constraints as symbols

alexmiller16:10:38

symbols cannot start with a leading digit

alexmiller16:10:08

the regex for keywords is subtly incorrect and allows keywords to have a leading digit

alexmiller16:10:33

by “fixing” that we discovered that people were using such things (at the time java.jdbc made result set keywords like that for example)

alexmiller16:10:04

there did not seem to be any good reason to break people’s existing working code so we rolled that back

alexmiller16:10:06

so it’s possible to read and use :1 and ::1 and we have no plans to make that stop working

favila16:10:31

it's deliberately not specifically allowed, however?

favila16:10:35

by specifications

alexmiller16:10:45

I would say that’s never been resolved

alexmiller16:10:20

CLJ-1527 is the ticket to do so

favila16:10:11

> Keywords - Keywords are like symbols, except: > They can and must begin with a colon, e.g. :fred. > They cannot contain '.' or name classes.

alexmiller16:10:35

“resolving” means making that reference page and the code in sync

alexmiller16:10:52

but the first question is what should be allowed

alexmiller16:10:10

there are plenty of other open areas for characters that are allowed in the reader but not explicitly allowed in the reference docs

favila16:10:41

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?

alexmiller16:10:09

keywords can definitely have dots in the namespace part

favila16:10:23

any way to fix those docs short of a jira patch?

favila16:10:58

"They cannot contain '.' after the first '/' or name classes" suggested edit

alexmiller16:10:19

It says “or in namespace names” ?

favila16:10:55

"keywords are like symbols, except: They cannot contain '.' or name classes." is what it says now

alexmiller16:10:13

oh, sorry I was looking at the symbol part

favila16:10:16

"are like symbols" is the handwavy part that I think causes most of the confusion

alexmiller16:10:16

I’ll look at an edit to that, but the intent again is to be similar to symbols and allow dots in namespaces

alexmiller16:10:06

agreed - the question is whether to describe two things as similar and then indicate differences or to restate, obscuring the differences

alexmiller16:10:18

I don’t feel that there is any ambiguity in intent that keyword namespaces should allow .

favila16:10:23

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"?

alexmiller16:10:38

well that is exactly the bug in the regex

alexmiller16:10:49

but I would say after the colon

favila16:10:31

the intent of the spec being: "expand ::, chop off the first :, and you should have a valid symbol literal"

alexmiller16:10:33

if you ask for the namespace and name parts of a keyword, you don’t see a colon. the colon is syntactical

alexmiller16:10:08

I don’t think that’s a semantically meaningful operation, so I wouldn’t describe it that way

favila16:10:03

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"

favila16:10:28

or at least thats how I am interpreting what you are saying.

alexmiller16:10:31

I understand what you mean. I just wouldn’t describe it that way

favila16:10:33

I think that's a little better than "keywords are like symbols," but still inappropriate for a capital-S "specification"

favila16:10:10

but I am glad I've discovered the authorial intent behind that phrase

favila17:10:03

That :a/b.c reads is an accident of history/implementation?

dominicm17:10:31

That isn't supposed to work?!

alexmiller17:10:19

I’d say that’s not supported in either symbols or keywords. whether it reads is a separate question

borkdude17:10:04

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?

borkdude17:10:01

hmm, no matter what options I give, custom-printer doesn’t work

borkdude17:10:53

thanks 😉

bbrinck18:10:04

ha, I didn’t really do anything 😉

bbrinck18:10:16

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)

borkdude18:10:51

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

borkdude18:10:36

oh wait, it does

borkdude18:10:31

@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

borkdude18:10:50

@bbrinck can I do the else branch in a nice way?

bbrinck18:10:35

@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

bbrinck18:10:41

Not exactly pretty 😞

borkdude18:10:32

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.

bbrinck18:10:15

I’m not sure exactly what you mean. Can you provide an example of the output?

bbrinck18:10:08

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?

borkdude18:10:08

until line 124 it’s ok, there I only print the keys of the system map. afterwards, still the whole system is printed.

bbrinck18:10:03

@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

bbrinck18:10:57

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)

bbrinck18:10:14

but in the context of spec, it will put all of the detailed explain-data into the exception

borkdude18:10:14

yes, it’s boot

bbrinck18:10:39

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.

borkdude18:10:26

I also tried this:

(try (rr/reset)
        (catch Exception e
          (throw (component/ex-without-components e))))

borkdude18:10:55

but that doesn’t work, because the assert exception already has the entire system in it :-s

bbrinck18:10:46

hm, not sure what you mean. Why can’t you alter the exception data in ex-without-components?

bbrinck18:10:53

is it already in the string message?

bbrinck18:10:13

if it’s just in the data, I presume you could just dissoc it

bbrinck18:10:05

or just construct a new error that has less info, using the message from the exception

borkdude18:10:28

hmm, I have to inspect the exception in the REPL to see what to dissoc, but good idea

bbrinck18:10:07

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

bbrinck18:10:28

basically just omit line 1964 and 1965

borkdude18:10:00

ah, right, that’s easier 🙂

👍 4
borkdude19:10:06

@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?

bbrinck19:10:46

Hmm, good question.

bbrinck19:10:24

Can you talk more about why a transform fn would be preferable to customizing the way it prints?

bbrinck19:10:42

Maybe we should move this to #expound since we’re talking about potential features