Parsing structurally encoded json is a pain. Not impossible but very annoying 😞

Just use (not-empty s).

I love it when the answer is simple but I also learn something from it.

not-empty does not coerce its argument.

Or rather, it doesn't coerce it to produce the result - only to check the emptiness. And blank? has different semantics.

yes, but not-empty does transform the string into a seq for the seq check

Right, that's what I meant in my second message. But it's just a construction of a wrapper object for a non-empty string - not a big deal.

Just sharing that Alex once recommended that to me, that's all ;)

Of course. It's just that one has to be really careful with the semantics here - much more careful than with a construction of a throwaway object (that on modern JVM seems to be a non-issue at all).

user=> (str/blank? "      ")
true

Sure, I wasn't saying that this is the answer to a question, just a comment that you might not want to create seq garbage from strings if you don't have to. May or may not be important.

But now that I'm reading back to the question, you're right that this is not what wevrem was after - I guess it was a knee-jerk reaction to: oh someone's using seq on a string again ;)

One man's garbage is another man's treasure. :) Clojure calls seq everywhere - I wouldn't even blink at someone calling it over a string, to be honest. It's doesn't actually transform a string, it doesn't traverse it. It just inspects its length, exactly once. If something is slow - one should profile it. I'm willing to bet that, unless there's a tight loop doing barely anything than checking string non-emptiness, seq will not come even close to the top of the "self time" on the profiler report.

Yeah, I agree with that, but since Alex said this to me, I can't unsee it ;)

I'm not sure if this is sufficient, but the LispReader class in clojure.lang has a symbolPat regex that looks like it might be used to read a symbol or keyword - <https://github.com/clojure/clojure/blob/5ffe3833508495ca7c635d47ad7a1c8b820eab76/src/jvm/clojure/lang/LispReader.java#L66>

This is intentionally not formalized. There are characters that are explicitly allowed and a few things explicitly disallowed, and a large intentionally ambiguous area for future expansion

I see

Which is not to say you can't tokenize it (obviously the reader does)

the thing is that I'm going to be tokenizing documentation that may have clojure symbols sprinkled within it and so tokenizing it as part of the full grammar isn't really possible

and so having an idea of what is allowed would let me guess if a stretch of text is a valid symbol or not

Symbols are intended to allow a pretty wide set of allowable things

sure seems like it from that pattern

doesn't a large ambiguous area mean that future expansion will likely break backwards compat for code in the wild?

just trying to understand things. this is super helpful 🙂

It would depend on what the expansion entails, wouldn't it? If it's expansion of disallowed, yeah, but if it's expansion of explicit allows, then it's "requiring less".

well from the sounds of it the ambiguous area is where things will be expanded, giving certain characters new meaning, which in turn may change the meaning of your code

if that's what you mean

sorry, I'm not 100% sure what you meant there exactly

There are probably not a lot of those kinds of things, but things like | for delimiting (similar to Common Lisp) is one thing we've looked at a couple times

If you want to do what Clojure does, then certainly follow LispReader (which has rarely changed)

cool, thanks alex 🙂

fwiw, I just meant that if, for example, the pipe symbol went from ambiguous/unspecified to explicitly disallowed, that'd be a breaking change, but if it went to explicitly allowed, that'd be a non-breaking change

Yes, which is why any such change would only be made with a lot of thinking and early notice