Fork me on GitHub

Speaking as someone who doesn’t own a project, I think it might be nice to create them with the caveat that project owners ultimately are in charge of changing them to fit their needs.

Alex Miller (Clojure team)01:06:51

Project owners should have that capability now afaik (but I haven’t tried it)


I was able to change the auto-assignee, at least I did that because I realized I wasn't getting emails for new tickets like I used to getting assigned will probably mean I get an email

Alex Miller (Clojure team)16:06:05

FYI, Contegix is experiencing a wide network outage. Contegix hosts the box for the Clojure build server ( and that is currently unavailable.


I'd like to reply to -- it seems an account was created for me, but I don't have access to any projects?

Alex Miller (Clojure team)18:06:18

oh, this came through the portal


speaking of which, can anybody authoritatively comment on TCHECK-155?


(that was not a question about jira commenting capabilities, it was a request for clojure design info)


it looks like the same old thing, the assumption that the universe of things that are valid for serialization(pr,read,edn) is the same as the universe of things


well in particular I'm thinking that exactly one of the following must be true A) the clojure reader accepting :/ is a bug and it should be fixed B) test.check should generate :/, because it's de facto valid and so useful for testing


but I can't tell which of those is true without an Official Ruling


My reading of is that: • keywords are symbols that start with :. • / is only valid in a symbol either by itself or separating ns from name (neither of which :/ satisfies)


you are missing the reader part of the url


or I am missing the entire context


(A is all about the reader)


> it looks like the same old thing, the assumption that the universe of things that are valid for serialization(pr,read,edn) is the same as the universe of things this doesn't sound right, because in this case :/ is fully readable and printable; the only thing it's at odds with is the documentation (and apparently something very subtle in cljs)


but the ticket seems to take the approach of removing :/ from the generated keywords


if we're committed to a situation where certain kinds of code subtly break and the only way to know that you shouldn't have written that code is to read things on , then that puts test.check in a pretty interesting position philosophically


so the question is is the keyword generator only supposed to generate keywords that serialize, or can it generate any possible keyword object that can exist

Alex Miller (Clojure team)19:06:17 is state what is supported, the code allows more than that but does not commit to it always working


@hiredman no, :/ can already serialize

Alex Miller (Clojure team)19:06:00

:/ is kind of a weird case because / was kind of wedged into symbol support and namespaced symbol support later on


sure, but the comment on the ticket, and it looks like the patch on the ticket removes it from the generator because it doesn't match the edn spec


where the edn spec is a spec about serialization, not a spec about objects that can exist in a runtime


(regardless of how faithful any of the readers are to that spec)


I don't think test.check should care about what the edn spec says if it differs from what clojure.core/{read,pr} do


or what they're intended to do, at least


why should it care about what read/pr do even?


I think that's more compelling than saying it should care about edn; edn's only interesting inasmuch as it's evidence for what's officially supported in clojure, but docs/comments about the clojure language itself are what we actually care about

Alex Miller (Clojure team)19:06:18

edn is intentionally a subset of clojure's syntax


you could also say it should just generate any object that can be created in any fashion, I'm not distinguishing those two at the moment


@alexmiller and that particular relationship (subset) doesn't resolve the :/ question -- :/ could be invalid edn, but still valid clojure

Alex Miller (Clojure team)19:06:44

right, my point being that edn is interesting because it's a format for external data files and is more restrictive than clojure

Alex Miller (Clojure team)19:06:59

such that it may be important to test with the more restrictive set


yeah, I imagine knowing it's a subset means that if something is valid edn, it must be valid clojure as well

Alex Miller (Clojure team)19:06:29

edn < clojure per spec < clojure per code

Alex Miller (Clojure team)19:06:58

any of those are potentially interesting for generators


yeah a cute thing test.check could do is test if (read-string ":/") succeeds, and avoid generating it if not that'd make it do The Right Thing in some future world where the reader gets stricter

Alex Miller (Clojure team)19:06:51

first question for this ticket is, can we resolve which set :/ is in


based on what you've said already I'd assume it's only clojure-per-code

Alex Miller (Clojure team)19:06:28

well, I might be able to resolve this better with the man upstairs


I'd be much more comfortable with this situation if :/ wasn't broken in cljs


I think that's the worst part; I'd argue either the cljs compiler & runtime should be modified to prevent creating :/, or the hash-code or whatever the underlying problem is should be fixed


I suppose test.check can detect that bug at load-time as well, and suppress generation of :/


but in general it's not obvious what a data generation library should do in this situation, short of providing multiple categories of generators 😕

Alex Miller (Clojure team)19:06:35

I frequently want generators from test.check that are similar to the existing ones in this kind of way


meaning you want stricter generators?

Alex Miller (Clojure team)19:06:58

I have no particular example in my head at the moment but have frequently found myself staring at the docs for generator namespace wishing I had something like what's there but slightly different


I thought a decent amount about expanding the generator API to make it easier to customize them

Alex Miller (Clojure team)19:06:28

the next time I'm in this bucket I'll drop you a note somewhere with an example


the cljs :/ bug seems to make them similar to NaNs

Alex Miller (Clojure team)19:06:04

that seems bad and fixable, even in the gray area of maybe-allowed


the idea was basically to add a third arg (in addition to rand and size), presumably called opts, which is just a map that gets passed down to leaves the same way size does, and can be customized in a similar sort of way


off the top of my head I can't remember any downsides

Alex Miller (Clojure team)19:06:02

I'd really like more flexible primitives so I can compose myself to glory, rather than options


it's easy to make your own primitives


the options would especially target situations where somebody else (e.g., spec) is assembling the generator for you


e.g., (def keyword-but-not-slash (gen/such-that (complement #{:/}) gen/keyword))


the hard part is tweaking a complex generator to never generate :/ anywhere


if there were an obvious right answer to this I would have done it already :face_with_rolling_eyes:


e.g., gen/any is not very useful if it has to dictate all these choices, and you'd get a combinatorial explosion of gen/anys if you wanted to provide all possibilities

Alex Miller (Clojure team)19:06:22

does test.check have edn-makers?

Alex Miller (Clojure team)19:06:36

or was that Stu's generative stuff that did that

Alex Miller (Clojure team)19:06:06

or maybe it's in clojure's own tests

Alex Miller (Clojure team)19:06:18

we use that a bit in some tests


that pool idea is interesting


I guess that's all against data.generators


With the latest homebrew release, I'm getting an odd thing where, in /usr/local/bin/clojure, it ends up with

Not sure what the root cause might be yet; just sharing.