Fork me on GitHub

@alexmiller: > I’m also not sure how easy it is to pick up a lein project.clj and actually parse it to a point of understanding its dependencies past a naive read. This is not very easy - you’ll need to resolve the project properly, and also optionally tell it which profiles to use.


I think perhaps Leiningen's project.clj contents can contain executable code, in general, although most projects don't take advantage of that.


This is certainly true. A good number of projects I would wager do take advantage of this in different profiles, namely test profiles. I suppose it depends on what you’re specifically referring to by executable code, though.


For example, Leiningen 2.7.1 fires up a REPL using 'lein repl' in a directory with this project.clj file contents:


(let [version-str (str "1" ".8." "0") proj (symbol "org.clojure" "tools.namespace")] (defproject execproj "0.1.0-SNAPSHOT" :dependencies [[org.clojure/clojure ~version-str] [~proj "0.2.9"]]))


Yes, this is the case, and you’ll definitely need to handle that. Another thing is that the lein resolution really has to be done with CWD set to the project location - lots of projects rely on that for various wierdnesses.


All of this is why the plan is to make things extensible in tools.deps, and let the community work on it as they want - I don’t expect to work on this in core


It’s also required to either set env vars, or hook lein - all this depends whether you want to do the resolution in-process or not.


Cursive has some really ungodly stuff to work around all this to allow the resolution to happen in-process for speed reasons - some users have projects of > 80 lein projects.


If you’re only interested in resolving one project at a time then starting a subprocess is almost certainly the best idea.


Hah, and if you think project.clj is hard to handle, just wait until you start looking at build.boot files which are just arbitrary executable Clojure code 🙂


well, no plans to do that :)


Hi. Recently I figured out a way to write and debug macros-generating macros more easily. I was confused by the different results I would get with println and pprint when displaying a list starting with the symbol quote. So i started to investigate and it turned out pprint explicitly translates (quote abc) to 'abc while the reader does the opposite job when expanding the reader macro '. I peaked at source code, and it appeared that translating [backtick]abc to ( abc) had been planned but commented out. So I wrote, as a pure development tool, a monkey-patch that enables syntax-quote <--> [backtick] translation in both the reader and pprint with this effect: Before

;; (quote my-ns/abc)

(pprint ``abc)
;; 'my-ns/abc
;; (clojure.core/syntax-quote my-ns/abc)

(pprint ``abc)
;; `my-ns/abc

(def args [1 2 3])

(pprint (syntax-quote `(abc [email protected])))
;; `(my-ns/abc 1 2 3)

(pprint (syntax-quote `(abc ~'[email protected])))
;; `(my-ns/abc [email protected])
But above all, it prevents this:
(pprint ``(do (fn1 arg1 arg2) (fn2 arg3 arg4)))

  (clojure.core/list 'do)
     (clojure.core/list 'user/fn1)
     (clojure.core/list 'user/arg1)
     (clojure.core/list 'user/arg2))))
     (clojure.core/list 'user/fn2)
     (clojure.core/list 'user/arg3)
     (clojure.core/list 'user/arg4))))))
And prints this instead:
(pprint ``(do (fn1 arg1 arg2) (fn2 arg3 arg4)))

`(do (user/fn1 user/arg1 user/arg2) (user/fn2 user/arg3 user/arg4))
The code itself is at I think this could be a great addition to Clojure (modulo the gory details of how I implemented it, especially the fact that I substitute Clojure's reader with that from What do you think ?


What problem are you trying to solve?


I made my case clearer in this snippet:


@tristefigure a change like this would be a breaking change, moving syntax quote from read-time to a macro, so it's highly unlikely that this will ever happen, especially when this sounds tooling could aid you in this


and the fact that its main use case is to aid debugging rather than a functional enhancement


i've felt your pain before, but realistically I don't think this will happen


Hi, I'm trying to write a tool that would read clojure datastructures from the output of a REPL or a log stream and that would reformat it (pretty printing for example). I have a problem with the print-level and print-length options which are common in this context and which make datastructures impossible to read. I think it would make sense to make print-method to print a tag reader when the print-length or print-level limit is reached. Is this something that has been discussed before ?


@cgrand has done something like this for unrepl


@ewen there’s a bit more to it as elided hashmaps have an odd number of items


@cgrand I see, but it should not be to hard to patch, if there is a willing to


I find printing already too complex


what do you mean ?


print-dup, print-readably controlling the main printer, the pretty printer being its own thing governed by hald a dozen of dynvars...


pprint also doesn't have the contract prn has of printing readable forms, but that doesn't stop people from expecting it


right, but prn printing readably is a very important property, everything else can be built upon


@bronsa: thanks for the feedback, I was expecting it. I struggled to find an example where syntax quote would differ with the change I propose with no success. Informatively, can you tell me how I should expect it to break things ? Does this hurt performance ?