try map->Foo

It gets generated by defrecord just like ->Foo

Perfect. I knew that should be included. 🌷

Oh cool. That's also how I can get "optional", but still specified fields. I can leave out a field in the map if I'm okay with it being nil.

What do you mean by optional, but still specified?

If you're not implementing any protocols or interfaces, you should be able to just use a regular map

Meaning the Record has the field, but I don't need to mention it on construction.

Even if you are implementing interfaces/protocols, you can also just create a record with no specified fields. You can always assoc additional keys.

Yeah, but a real field is slightly different from being able to assoc on arbitrary keys later.

In potential performance, but also in self-documentation of intended use.

I don't think I've ever seen that final attr-map? actually used in practice. But a toy example:

(defn foo "Returns true if all arguments are greater than zero"
  {:version "1.0"}
  ([x y]
   {:pre [(every? number? [x y])]}
   (every? pos? [x y]))
  ([x y z]
   {:pre [(every? number? [x y z])]}
   (every? pos? [x y z]))
  {:another :attribute})

It get's merged into the function's metadata:

(meta (var)) =>
{:another-attribute :bar,
 :arglists ([x y] [x y z]),
 :column 1,
 :doc "Returns true if all arguments are greater than zero",
 :file "playground.clj",
 :line 1,
 :name foo,
 :ns #namespace [playground],
 :version "1.0"}

thanks

A function body already implies do semantics. Each form will be evaluated, and the output of the last expression is returned. {:on-click #((do-thing) (another-thing))} If that isn't working, then either there is some other bug in the code or you are bumping against the limitations of the #() macro. Not all functions can be correctly transformed by that macro.

got it, thanks!

If I understand correctly, the reading of a #(form) form gets converted into (fn [args...] (form)) , meaning there is no implicit do like for fn. So the do must be added manually like you have 🙂

Yeah. Sorry Wen Hou. I made a mistake in my previous post, because I would not even be trying to use the lambda macro that way. I reserve #() for very short and straight-forward functions. What I said is true for normal lambdas, but not for #().

{:on-click (fn [] (do-thing) (another-thing))}

The problem is the macro expands into a function-of-a-list-of-forms, instead of into a function-of-multiple-forms.

(macroexpand `#((prn :foo) (prn :foo)))

(fn*
 []
 ((clojure.core/prn :foo)
  (clojure.core/prn :foo)))

(fn*
 []
 (nil (clojure.core/prn :foo)))

i see, this is similar to the issue (#([1 2])) won’t work, i should use (#(vector 1 2)) . thanks for explaining, i learned how to use macroexpand 🙂

It might be interesting to point out, as was said, that #(...) is a reader macro, not an ordinary macro. This means that the transform to fn* happens at read time, which is before compile time. Try evaluating this:

(read-string "'#((prn :foo) (prn :foo))")

And there is also macroexpand-1, in case of nested macros that you only want to view the first rewrite. macroexpand calls macroexpand-1 in a loop.

@U024X3V2YN4 i am not sure i understand, is there good resources i can read to understand why #(…) has to be a reader macro ?

Clojure has a number of these reader macros . You can learn more about them at https://clojure.org/reference/reader#macrochars and https://en.wikibooks.org/wiki/Learning_Clojure/Reader_Macros. These macros modify the behaviour during the read phase, while macros created by defmacro are functions that take what's returned by the reader and converts it to another expression during the eval phase.

cool, thanks !

Reader macros can transform the syntax of the language entirely (in this case giving special meaning to a # prepended to a list). Plain macros calls appear as the first entry of a list, just like function calls. Many Lisp languages let you define your own reader macros. But Rich intentionally left that feature out of Clojure to avoid the community fracturing into different dialects with varying resemblance to the base language.

Leiningen is still a big player, Boot is out there but I don't know that it has a ton of market share, and another big player is the deps CLI: <https://clojure.org/guides/deps_and_cli>

I do not hear much about Boot these days. Leiningen is still super popular and my favorite. The new deal is deps. When trying sth new, I just start from its intro repo and inherit whatever build tool it used.

Going to run with Leiningen, then!

btw, when Brave/True came out Boot was indeed the new kid in town catching a lot of enthusiasm.

I'm a relative newcomer to Clojure myself but my two cents (if they are worth that) is to use Deps CLI. I find the guides quite thorough and there's also https://github.com/seancorfield/deps-new

Oh no - choices! 😉

Build tools: the Dark Side of Clojure. 👹

I guess there’s a dark side to every ecosystem. With Python it’s packaging that everyone hates and complains about.

@U049KEXDHL5 See https://clojure.org/news/2022/06/02/state-of-clojure-2022#_working_with_clojure for a graphic of relative use of Leiningen, CLI/`deps.edn` and other tooling. That survey was run early this year so you can extrapolate where we are now and where we are going.

Ah, OK. Bye bye, Boot.

At work, we started with Leiningen back in 2010-ish, switched to Boot in 2015, then to the CLI and deps.edn in 2018. And we're very happy with that for our 130k line monorepo, building two dozen services. See https://corfield.org for some blog posts about our switch to Boot and our later switch to the CLI if you're interested in more detail.

Excellent, thanks!

Yeah, Leiningen is still perfectly viable and probably easier for beginners to explore Clojure. I would stick with that, especially when following books/tutorials using it. The community is gravitating more towards the cli/deps.edn and when you are ready to explore those I find this video pretty beginner friendly: https://www.youtube.com/watch?v=8aCO_wNuScQ

I would recommend leiningen for beginners

Tools.deps is my choice now too but without a good mental model for the data structures it’s quite confusing how all the tiny granular confit pieces you write merge together

Config

I don't see the problem with the clojure CLI to be honest. What stops a beginner from starting with an empty deps.edn and adding stuff to it from there organically, as they need it? What does leiningen offer out of the box that the clojure cli doesn't (and how does that make it confusing)? And would it be less confusing to learn leiningen and then switch at some point? edit: that said, I don't think it matters what you choose, both are good at what they do

The Clojure code for the app / library being written is the same regardless of build tooling. Leiningen is an all-in-one tool, so only Java and Leiningen install and your ready to code. Clojure CLI is very flexible and highly configurable, so initially a little more config (learning) involved, but after that there is not much difference. I maintain https://github.com/practicalli/clojure-deps-edn which bootstraps the Clojure CLI configuration with a large range of community tools to give more of an all-in-one experience

lein help lists all the tasks it can do, many of these tasks require a community tool for Clojure CLI. switching between Leiningen and CLI is a matter of creating a deps.edn file with the same dependencies, as long as Leiningen plugins that do a little magic with code are not involved (e.g. lein-ring). Leiningen dev-dependencies would become Clojure CLI aliases (as optionally would Leiningen profiles and aliases) There is some community tooling to help create a deps.edn from a project.clj if really needed. If there is some Clojure code in project.clj other than defproject (this is relatively rare) then that would probably be added to a custom user.clj file (or just not included) It's possible to have both Leiningen project.clj and deps.edn configs, although dependencies should be kept in sync, so typically one configuration will eventually take precedence. I don't see any issue starting with either Leiningen or Clojure CLI and then learning to use the other one as required, they have a lot n common and share a lot of the same features, although Clojure CLI needs to be configured to include many of those features.

@U05254DQM wrote: "Clojure CLI is very flexible and highly configurable, so initially a little more config (learning) involved" I think this is where the wheels come off for me. I just want to write my app. I am not interested in learning how to build, beyond what should be three commands. Back in the day we had one command for compile, one for link, away we went. sigh But thx for the motivation! I was going to whine "Where is lein deploy clojars for deps?" and checked and discovered https://github.com/slipset/deps-deploy. Looks promising! I actually do not like being behind the eight ball technically, and deps is clearly the future... is there a "Deps for dummies" article out there, or mebbe a "Deps for Leiningen refugees" write-up?

For many projects and teams it’s perfectly fine to stick with Leiningen, especially if it’s a very (Leiningen) standard project setup and Leiningen just works for the team. However, there are setups and teams that want to take a different approach to that provided by Leiningen (which has some constraints, especially around plugins). Configuring and customising Clojure CLI is simpler in my view (not necessarily easier when used to Leiningen). I would encourage teams to look at Clojure CLI when they have time to do so, as its an approach that I find very productive and a very declarative and data centric approach. Although do remember that Clojure CLI was not designed as a replacement for Leiningen, but can be a very effective foundation for providing the same functionality in a highly flexible way. tools.build is also evolving very nicely to complement Clojure CLI and allow for a simple yet powerful build tool approach.

In https://github.com/practicalli/clojure-deps-edn#common-development-tasks I have tried to capture most of the common tasks for a Clojure project, with their command and if the aliases required are built into Clojure or part of the project or user deps.edn configuration

> Build tools: the Dark Side of Clojure. laughs in Maven and Gradle

for me, lein feels a bit more like build tools from other ecosystems, which is probably a great place to start.

while deps has a more minimal, “i’ll tell you what tools i need and how to run them” thing going on

Thanks for the plethora of thoughtful replies, folks!

Good luck with the book!

Thanks, @U017QJZ9M7W