There was an attempt to make those keywords unreadable a few years back, but it got reverted because it broke stuff

https://clojure.atlassian.net/browse/CLJ-1252

I think there may be some inconsistencies in the support of numeric keywords as well, like depending if they have a namespace component or not you get different behavior (not sure though)

The https://clojure.org/reference/reader#_literals reader docs seem similarly ambiguous on this issue.

I think the position is something like "would rather not allow it, but unwilling to break code that relies on it"

ok.

It's clear that patch is trying to rule out :500, but it's not clear (to me) if :5withletters is even desired to be acceptable in any of the docs.

maybe a good rule of thumb is, if it's an invalid symbol, it should probably be regarded as an invalid keyword?

I've seen numeric keywords used in deps.edn aliases etc for different clojure versions {:aliases {:1.11 ...}}

The reader docs say, keywords are like symbols, except ...

so I'd say, the same rules apply to the namespace / name

> maybe a good rule of thumb is, if it's an invalid symbol, it should probably be regarded as an invalid keyword? "it should" presumable refers to the name of the keyword?

Valid/invalid isn't great terminology, would be better to use readable/unreadable

FWIW:

user=> :1
:1
user=> :1/a
:1/a
user=> :a/1
Syntax error reading source at (REPL:4:0).
Invalid token: :a/1
user=> :1a
:1a

well, valid/invalid according to the docs, is what I meant. readable depends on the implementation of the reader

No, the docs you are pointing to are intended to be reader docs

> Valid/invalid isn't great terminology Valid/invalid is great terminology. I'm looking for something that is forward compatible and expected to be readable by a wide variety of readers.

The keyword function will make a keyword that prints as :///500 and that keyword is a real valid keyword

Just not readable

I'm specifically referring to edn readers.

Sure, what make invalid/valid bad is because it is easy to confuse the context of that validity, in a discussion about readers valid/invalid makes sense, but it seems like already, in this context about readers, it can still be confusing what invalid/valid mean

Readable/unreadable carry more of their context with them

Maybe, but just because something is readable now in a particular context doesn't help with knowing whether it will be readable in many contexts now and in the future (which is what I'm actually interested in).

The edn spec exists as well https://github.com/edn-format/edn?tab=readme-ov-file#keywords

I think there's enough prior art out there of keywords that start with a number that no usable tooling is going to appear that doesn't support them, even tho' they are "invalid", so they will always be readable at this point.

The distinction there is what the spec says is readable, vs what readers support reading

The quotes in the original question are from the edn spec.

And those are different sets, so what the spec says is unreadable as a keyword is not the same set as what a given reader may treat as unreadable

The smallest of those sets is what the spec defines as readable keywords, which does not include keywords that start with numbers

> Keywords follow the rules of symbols, except they can (and must) begin with : I think it's at least a little bit ambiguous as to whether :5withnumbers starts with a number since it actually starts with a :.

I think the language is ambiguous, but the intent is clear in the context of writing a recursive descent parser (like the reader)

Presumably, the intention is that all the restrictions that apply to the first character's of symbols applies to the second character of keywords.

: says that what follows is a keyword, and then you can parse what follows as a symbol, and then transform that symbol into a keyword

The spec for symbols themselves is written in such a way that you can read it as taking 5foo as not readable and bar/5foo as readable, because bar/5foo doesn't start with a numeric character, but I don't think any existing reader allows that

I'm never using keywords again.

https://clojurians.slack.com/archives/C06E3HYPR/p1716924986383909?thread_ts=1716922866.870989&cid=C06E3HYPR somewhat related but regarding . In the name part of the keyword

Well, that is also another kettle of fish again because the reader spec mentions treating symbols with . in specially, but actually that isn't something the reader does(iirc), that is part of the evaluator / compiler, so maybe doesn't belong in the reader spec at all

I think if I were trying to make the read spec more rigorous I would start with defining something like a "readable simple symbol" which is a symbol that is not namespace qualified, and then say a "readable symbol" is a pair of simple symbols separated by a / and a keyword is : or :: followed by a symbol. I think that would make the definitions a fair bit more rigorous while maximally preserving the intent of what is there now. The trade off is introducing the synthetic concept of a "simple readable symbol", but a similar concept has already been useful enough to introduce clojure.core/simple-symbol?

And ident? / simple-ident? too. For symbols or keywords.

I realized my description was a bit ambiguous. I have a library managed with deps.edn that I want to consume from a lein-managed application.

If you look at the build.clj in a project generated by deps-new, you'll see an install function for that...

It uses deps-deploy

Thanks @U04V70XH6, I’ll check that out. This is related to the cache conversation we had the other day. I see the project has a pom.xml too so maybe that’s taking me in the right direction. I’ll poke around

You have an old version of deps-new if it produces a project with a pom.xml file...

Sorry, I meant clojure cache already has one: https://github.com/clojure/core.cache/blob/master/pom.xml

Yes, all Contrib projects historically used Maven

I’m just trying to test out the locking hacks I added the other day in a different project

The deps.edn files in Contrib projects are a convenience -- not how the projects are built.

Contrib libs are built via a core GHA workflow that uses mvn: https://github.com/clojure/build.ci/blob/master/.github/workflows/snapshot.yml#L25