Clojure Q&A - Recent questions tagged feature

bit-count in cljs but not clj

Fri, 30 Jan 2026 09:21:40 +0000

The bit-count function ships as part of CLJS but not CLJ, which means I end up using a reader conditional to use Long/bitCount on the JVM side when I write cljc files. It would be nice if I could just use bit-count.

(I chose "compiler" for category because there's no option for "standard library")

Using namespace as log originating class for JUL

Sun, 05 Nov 2023 14:03:39 +0000

When using tools.logging and java.util.logging (JUL in short), by default we get logs prefixed like this:

Oct 23, 2023 2:14:47 PM clojure.tools.logging$eval3668$fn__3671 invoke

Notice that class and method name logged are something completely unhelpful.

The solution recommended by the tools.logging library is that the user should change log appender output format to not print out class and method and to print out the logger name, which is the Clojure namespace name.

That is a possible solution when the authors of the app doing the logging and the author of code that configures JUL are the same person, i.e. the logging is configured and done at app level.

Use Case

I would say that the far more common use case of tools.logging is the use by a library author, who doesn't know which logging solution the end user is using. And at the same time, the end user is unaware of this logging being present in their dependency tree. In this case someone builds a Clojure app and they might have a 100 dependencies. Suddenly they start getting messages as described above in their stderr.

They might want to:
- redirect that to a file
- suppress the messages
- want to know which dependency is generating them

All of these tasks require that the user recognizes that it's JUL logging they are looking at and then configuring the JUL to output logger name to find out the namespace which is doing the logging. They might also want to keep the format with the method name for any Java code they have.

Approach

Use LogRecord class to force classname to Clojure namespace. Example code:

(cond-> (doto (LogRecord. level# ~msg)
                      (.setLoggerName ~ns)
                      (.setMessage ~msg)
                      (.setParameters (object-array ~params))
                      (.setSourceClassName ~ns))
              ~e (doto (.setThrown ~e)))

Benefits

Replaces clojure.tools.logging$eval3668$fn__3671 invoke in output with my.lib.namespace. The former string has 0 informational value, the latter enables us to know where to look for the log statement performed.
Improves performance. If .setSourceClassName is called, then the logging system won't use reflection to determine caller class and method. That involves walking the stack trace and it's slow.
Even with default/no configuration of JUL it gives a hint about where to look for who is making all these messages in stderr, if user is not aware of this logging library/mechanism.

I can produce a PR to affect this change if needed.

alarm function

Thu, 05 Aug 2021 02:02:35 +0000

Alarm Function

Simple description:

The alarm function is a feature, that call a function every period of time .

Use:

(defn function
  "This function will be called every 1 minute 10 times"
  []
  (println "Hello, world!"))

 (defn -main 
  ""
  [& args]
  (alarm 1 10 function))

Simple use case:

When a user create account and not confirmed email. through the alarm verify if the user really not confirmed

Conform function Specs at read time similar to macros?

Thu, 26 Nov 2020 21:57:39 +0000

I think there would be value in having Spec conform the literal code passed to functions the same way they do for macros. Maybe fdef could take a :syntax spec as well which would be used for that.

There are quite a few functions I think this could be useful for. A lot of functions will take options for example as keywords, those are most likely going to be provided as literals, so conforming their usage for function calls at read time would be valuable.

Other examples where this could be useful are say even for simple usages like +, where the args often contain literal numbers as well, where again the spec could validate that say a keyword or string literal isn't passed to it at read time as a syntax error.

In effect, I find a lot of Clojure functions themselves have function specific syntax, and it would be great if Spec could be used to conform their syntax at read time the same way it lets us do so for macros.

Add limit third argument of split to split-lines

Sun, 24 May 2020 20:09:51 +0000

The signature for clojure.string function split-lines is:

(split-lines s)

And the signature for split is:

(split s re)
(split s re limit)

I think it would be nice to add this overload that accepts a limit to split-lines as well, just as it is for split:

(split-lines s limit)

My use case is often to split on lines but not to ignore trailing newlines. This requires passing -1 to limit. In those cases, I always need to switch back to using split and re-implement split-lines.

How hard is it for Clojure to have readable closure?

Fri, 22 May 2020 12:52:48 +0000

The language's name is obviously derived from "closure", yet readable closures seem to be Elisp unique feature.
How hard is it for Clojure to have such ability? Of course many types can't have their readable stringified form, but what about closures containing the ones that can?

Is it possible to parse positional arguments in tools.cli?

Tue, 07 Apr 2020 08:06:38 +0000

It's rather a rhetorical question as I've come to understand that tools.cli is not capable of doing anything with positional arguments but passing them on to the consumer of the library as strings in a vector. But I'll share my usecase.

I'm writing a tool that copies files from one directory to another. It takes two positional arguments, the source and destination. Right now my code contains two passes of input verification and parsing, first one for options with tools.cli and then a second one for arguments in my own function parse-arguments. It would be neat if these two things could both be done with in one step.

See the below code for a usage example.

(ns multi-machine-rsync.cli
  (:require [clojure.tools.cli :as cli]
            [clojure.java.io   :as io]
            [clojure.string    :as string]))

(defn read-settings
  [path]
  (read-string (slurp path)))

(def cli-options
  [["-h" "--help" "Show this help text"]
   ["-s" "--settings SETTING-FILE" "Path to the settings file."
    :parse-fn read-settings
    :default  "settings.edn"]])

(defn usage
  [options-summary]
  (string/join
   \newline
   ["Copies a directory from one place to another in a common"
    "directory structure using multiple machines."
    ""
    "Usage: multi-machine-rsync [OPTIONS] SOURCE DESTINATION"
    ""
    "Options:"
    options-summary]))

(defn parse-arguments
  "Parse and validate command line arguments. Either return a map                                                                                         
  indicating the program should exit (with a error message, and                                                                                           
  optional ok status), or a map indicating the action the program                                                                                         
  should take and the options provided."
  [args]
  (let [{:keys [arguments options errors summary]} (cli/parse-opts args cli-options)
  	[source destination]                       (map io/file arguments)]
    (cond
      (:help options)              {:exit-message (usage summary) :ok? true}
      errors                       {:exit-message errors}
      (nil? source)                {:exit-message "First positional argument SOURCE not given."}
      (nil? destination)           {:exit-message "Second positional argument DESTINATION not given."}
      (not (.exists source))       {:exit-message "Source directory does not exist."}
      (not (.exists destination))  {:exit-message "Destination directory does not exist."}
      :else                        {:options      options
                                    :source       source
                                    :destination  destination})))

Would be nice if tools.namespace.find functions return file info in ns-decl meta

Tue, 05 Nov 2019 13:35:01 +0000

Currently calling tools.namespace.find/find-ns-decls returns a seq of ns-decl for a given dir or collection of paths but there is no way to know where did they came from (can also be coming from paths inside jar files).

Looks pretty straight forward to add file info as meta of the ns-decl form. Something like https://github.com/jpmonettas/tools.namespace/commit/1431215324ba7f76f78342742ce3716ec8c5abb8

What do you guys think?

(Filed jira at https://clojure.atlassian.net/browse/TNS-55)

Add text block literal, or raw string literal, or unsescaped string literal.

Tue, 03 Sep 2019 22:46:52 +0000

Problem:

Having had to include some JavaScript, XML and HTML inside of my Clojure code here and there, it can be pretty annoying and error prone to have to escape quotes. This holds true as well when scripting, and running shell command, you can get into hairy escaping scenarios.

Solution:

Add a string literal which can be adapted to contain any sort of string without the need for escaping.

Suggestions:

Text blocks

Some other languages offer something called a text block where you can write a string using triple or more quotes, where all characters are then allowed:

(println """
         This " is allowed,
         and no need to escape it.
         """

Text blocks often come with additional features, such that the first and last newline isn't part of the string. And the position of the triple quote in the source code delineate the beginning of the lines in the quote. Thus the above code prints:

This " is allowed,
and no need to escape it.

and not:

         This " is allowed,
         and no need to escape it.

While text blocks are neat visually, as they have nice alignment in the source code. They are whitespace dependent, and Clojure up to now is a whitespace independent language, meaning whitespace does not matter. I think it would be best to keep it that way. Thus the next two suggestions.

Raw strings

Sometimes the text block without the "block" features is known as a raw string literal:

(println """This " is allowed,
and no need to escape it.
Also support multi-line, but
not the "block" style of text blocks.""")

Thus:

(println """
         This " is allowed,
         and no need to escape it.
         """

Prints:

         This " is allowed,
         and no need to escape it.

Unlike for Text Blocks.

If you need a triple quote, just make the delimiter a quadruple quote:

""""This """ is now allowed as well.""""

The issue with raw string is that, if you use say double quotes as your delimiter:

""This is a raw " string!""

But want your single quote to be at the beginning or the end:

"""{{hello}}"""

I want the string: "{{hello}}", not {{hello}}, but the raw string can not disambiguate the two, as now it thinks this is a triple quoted delimiter.

One solution is to allow an escaped quote only at the beginning or end:

""\"{{hello}}\"""

But not in the middle:

""\"{{he\llo}}\"""

This is the string: "{{he\llo}}"

So the escape character \ can appear anywhere except at the beginning if followed by a quote, and at the end if followed by a quote.

I still don't find this ideal. There's too many rules, and there are still cases where an escape is required.

Unescaped string (my favorite)

The idea here is to allow any string to be used as the delimiter. Thus given whatever possible string we want to nest inside our Clojure code, we can always find a string which is not contained in it to use as our delimiter.

Lets say the reader macro #text is added. Which expects the following form to be a regular string which tells it the delimiter for the following form to read:

(println #text "|" |"{{hello}}"|)

Would print:

"{{hello}}"

The first arg to #text tells it what the delimiter for the following raw string should be. That way, you absolutely never need an escape sequence inside the raw string. For any given string, you can find a delimiter string not contained in it to handle it properly.

A crazy thought I had with this approach, just trowing it out there, is if you use a sufficiently random string as the delimiter, could be a weird way to protect against forms of injection:

(println #text "xIBgdSl4TCCOIdqdMu9G" xIBgdSl4TCCOIdqdMu9G
Can't nobody guess the delimiter to escape the string context :p
xIBgdSl4TCCOIdqdMu9G)

Thank You

Add digit separators support to number literals.

Tue, 03 Sep 2019 19:40:15 +0000

Just saw as part of Go 1.13 they added:

Digit separators: The digits of any number literal may now be separated (grouped) using underscores, such as in 1_000_000, 0b_1010_0110, or 3.1415_9265. An underscore may appear between any two digits or the literal prefix and the first digit.

And I thought that's a pretty neat feature. When writing big numbers, such as 92347683 it can be hard to read and parse mentally if this is million, billion, etc. Having a syntax for separation I think would be a nice addition to the reader. Doesn't have to be underscores, and might need some hammock time when considering all the valid Clojure number literal.

Thank You

Add ability to use ~ or reference user.home inside tools.deps local/root path

Fri, 30 Aug 2019 07:39:47 +0000

When using local/root provider in tools.deps, it would be nice if you could reference your user.home. I share a user level config between machines which have different home location, but my dependencies are all relative to it.

Specifically, this is with my use of REBL, I have the Jar in my home dir, but different home dirs on different of my computers, and would like to not have to customize the deps.edn for each one.

Thank You.