Was it ever considered to use #[] for e.g. persistent queues?

Some sort of persistent queue literal has been discussed on and off since 2012: https://ask.clojure.org/index.php/3365/implement-reader-literal-support-persistentqueue-structure

(that links to a few JIRA tickets too @suskeyhose)

thanks

I think https://cljs.github.io/api/syntax/queue-literal is what cljs does

Yeah, I think that's what the Jiras behind the Ask above ended up going with but I haven't checked the patches.

Having thought about it for many years, my current thought is that queues are not common enough to warrant syntax

Just my personal opinion

In our 120K line code base, we have just three PersistentQueue/EMPTY instances. One of those is in a test. One is in some production code but intended purely as a debugging aid. Only one is in mainline production code. Definitely not worth having a literal for us.

I do think a constructor function would be useful

Like this:

user=> (defn queue [& args] (into clojure.lang.PersistentQueue/EMPTY args))
#'user/queue

that would be good, yeah

Hi Everyone, I'm looking for a library in Clojure (or Java for that matter) that can take a JSON document, or the schema of the document, and generate sample JSON that conforms to the schema. So far my Google-fu has let me down.

Crazy idea: I read somewhere the way to think about the Clojure REPL is: (1) you have some blob of live state, and (2) you submit code against it. This sounds a lot like a database, except the live state is not in relational form. I was wondering: are there any database oriented libraries, or database oriented languages in the following sense: In most current situations, code is 'first class' (IDE for it, github to save history, etc ...) while 'data' is often 2nd class. Is there any language setup where code & data are equally valued ?

How is everyone handling errors in their Clojure programs? I don't think exceptions work very nicely in Clojure so I was wondering what alternatives there are

Does the phrase “tyranny of the container” to describe typed languages originate from one of Rich's talks? I forget where I initially heard it but I use it all the time. At work (Scala shop) and my colleagues are getting pretty sick of hearing me mutter it under my breadth.

On Java 11 I'm calling this method *newFileSystem*(*Path* path, *ClassLoader* loader) as (FileSystem/newFileSystem (.toPath ...) nil) which is fine and doesn't need any reflection. But on Java 17, there are more overloads where the second argument can be a different type, so I'm getting an error since the compile doesn't know which one to choose:

static FileSystem
newFileSystem(Path path, ClassLoader loader)
Constructs a new FileSystem to access the contents of a file as a file system.
static FileSystem
newFileSystem(Path path, Map<String,?> env)
Constructs a new FileSystem to access the contents of a file as a file system.
static FileSystem
newFileSystem(Path path, Map<String,?> env, ClassLoader loader)
Constructs a new FileSystem to access the contents of a file as a file system.

You use let, bind nil to a name, type hint the name

ah gotcha! thanks

worked like a charm, thank you @hiredman