Can you override a defmethod only within a form? Similar to how with-redefs can redef a normal function only within its form?

is there a less-icky way to say “if this isn’t in a seq, put it in one” without flatten?

(flatten (conj [] x))

that is terrible

(if (seq? x) x [x])

never do that other thing

(seq? can be seq?, coll?, sequential?, your pick)

(cond-> x (not (seq? x)) list) maybe if you feel fancy

the real fix is to never have something that sometimes returns a collection and sometimes doesn't; as a consumer of a bad api you don't always get to make that choice though

yea past-me is really bad at writing apis 😞

(I have a few of those at work, in code written years ago, and I shudder every time I have to interact with those functions)

I ended up writing my own using get-method remove-method and defmethod

Is there anything like lein-ancient, compatible with deps.edn? https://github.com/xsc/lein-ancient

Yep! https://github.com/Olical/depot

Any love here for AWS ElasticBeanStalk? I just managed to set a Java project up, and it seems to be working nicely (as in, I don’t have to worry about much, just upload a new uberjar and everything seems to be going well). Any horror stories I should know about?

So, I built an uberjar with lein, and I've stepped on a static initializer based problem

when i "lein run" the problematic static initializer is not run unless I execute the codepath that depends on it

when i "java -jar" the static initializer runs, and it's a problem for some codepaths that do not depend on it

(surprise, it's SOAP libraries)

So how are people deploying web apps these days?

CodeDeploy to EC2 instances in AutoScaling Groups behind a ALB. All created via terraform. Uberjar generated with pack.alpha

Trying to remember a blog or Hickey talk/essay but my google skills are failing me. It basically describes clojure as a good language to use in long running systems with requirements that change over time and have to deal with messy human inputs as opposed to things like compilers that generally have a more fixed idea of the world and more slowly changing requirements etc. Does anyone know the post?

it was his keynote at the Conj last year @bwstearns

https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/EffectivePrograms.md

Thanks!

I couldn’t quite remember the term “situated program”

am i doing something wrong here reading in env vars at startup?

(def config (read-string (or (System/getenv "MY_ENV_FOO") "5")))
...
(with-redefs [some.ns/sym config]
  (run-app)))

@lwhorton First off, I'd advise against using def for something that interacts with the environment since it will run whenever the namespace is loaded (e.g., at compile time). Second, that error sounds like something expects some.ns/sym to resolve to a hash map?

The stack trace should tell you which line of code is complaining about that.

(oh, and from a security standpoint, don't use read-string on arbitrary external data -- it can be made to run arbitrary code and thus "hack" your application!)

Use something like Long/parseLong if you just want to safely turn a string into an integer.

what do you use instead of a def? just inline the System/getenv and don’t def it?

ah… i see the other problem now- i’m using with-redefs which is a macro. so i’m mixing my compile time + runtime. thanks for the info @seancorfield

Is it a known issue that the spec for valid Clojure symbols (https://clojure.org/reference/reader#_symbols) is wildly inaccurate? The EDN spec if correspondingly wrong (https://github.com/edn-format/edn#symbols), which is the context in which I encountered the issue. It seems essentially any Unicode character not otherwise reserved can be used, including some insane ones like \0:

=> (type (clojure.edn/read-string "µ"))
clojure.lang.Symbol
=> (type (clojure.edn/read-string "🔥"))
clojure.lang.Symbol
=> (type (clojure.edn/read-string "\0"))
clojure.lang.Symbol

As someone implementing an EDN parser, this discrepancy is pretty confusing

> A symbol can contain one or more non-repeating ':'s. what does non-repeating mean? non-consecutive?

There's a lot in the specs that the implementations don't validate. But if you go outside the spec, don't be surprised if future validation tools throw errors at you.

So I guess if you're implementing an EDN parser in another language, you have two options: either follow the spec, and break on certain EDN that works with the official parser. Or try to match the official parser, but know you're "wrong" and it might break in the future.

I love EDN, think it's a great data format, but that makes it very hard to justify using for any serious cross-language project

If you're building inbound validation into your implementation, you should probably implement to the spec.

if you're looking for cross-language EDN semantics, it's already built: Transit

Transit is great, but not if you want human readability

As a lib author, I wouldn't worry as much about breaking on certain EDN that happens to work with the official parser. The core stuff has to be a little more permissive for historical reasons. And perhaps some performance reasons. But a stricter implementation would probably be welcome by a lot of folks.

@polymeris Yes. But the CLJS reader doesn't catch that one

It isn't clear to me what might break in the future if you match the "official parser" behavior when reading. As far as I recall, at least, the English spec is strictly more constrained in what it allows as compared to the official parser.

Agreed that if you write code that generates EDN that is outside the constraints of a future more-strict-parser, that more-strict-parser will not accept such files.

My point is that a spec is only as useful as its most popular implementation. If clojure.edn can generate, and parse, EDN data with symbols outside the defined spec, what is the purpose of the spec? A user could justifiably say "I made this EDN file using Clojure itself - why can't your tool read it?" and "the spec says so" wouldn't be a satisfying answer

Note that the Clojure reader docs don't even cover all the symbol characters used in clojure.core (!!!) - < and > are definitely missing, maybe more

I have discovered this issue working with syntax highlighters in the past too where allowable-but-non-spec-conformant symbol characters were syntax highlighted incorrectly or threw errors

You can vote on this issue if you are interested in maybe seeing tighter docs on this topic: https://dev.clojure.org/jira/browse/CLJ-1527 Some of the description and comments on that issue list some of the things you mention, and perhaps others you haven't seen yet.

If you want tight specs with sharp edges for "in" or "out" on every question, Clojure and EDN are not currently the kind of place where those abound.

Or I guess as you point out, there are multiple tight specs (English, spec, code implementations) that do not match each other exactly.

Given the Clojure core team's strong emphasis on backwards compatibility, Hyrum's Law comes into play: http://www.hyrumslaw.com

Ah I missed that issue. Thanks for the link!

I think a "living spec" based on the Clojure implementation is a great approach - I just think it's misleading to have an "official" spec/documentation that doesn't line up with reality

Especially since the EDN spec claims a formal (i.e. BNF) specification is forthcoming (as of 4 years ago...): https://github.com/edn-format/edn#spec

My guess: If you implement something compatible with the current implementation, that is likely to change more slowly than the docs.

Does anyone ever switch out clojure.core for their own version eg. (ns foo (:refer-clojure :only []) (:use my-stricter-clojure.core))?

I've seen some newcomers suggest the idea, I've never seen it in practice