pprint

[Alex Miller]

jira/patch welcome...

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

pprint

[Mark Engelberg]

Is there any way to make Clojure's pprint print the record tags for
records? It seems odd to me that Clojure's main printer has evolved
improved support for records over the years, but pprint still prints
records as a plain, untagged map.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to get result of default pprint from custom simple-dispatch

[MS]

I have a defrecord which is not pprinting exactly the way I want.

When print-dup is true, I want to eliminate any references to the 
namespace, as I want to write out to edn and read it back in, but without 
running eval while doing so, and without exposing the clojure 
implementation details to the user who ventures into reading the edn file.  
This is not for security, just to keep the edn file independent of 
namespaces.  The defrecord I'm printing has references to other defrecords, 
which also have an abbreviated form for edn writing.

When print-dup is false, I just want pprint and pr-str, etc., to show the 
defrecord name with the namespace, then the map, but normal pprint doesn't 
show the defrecord name.

I've resorted to copying most of pprint-map from the clojure source into my 
simple-dispatch.
This seems like overkill, but it gets what I want.

Can someone comment if this is the right way to go about it?  Is there some 
way to call the built-in (but private) pprint-map directly on my defrecord, 
after printing out the class name?


(ns toydb.edn.shapes
  (:require [jfxutils.core :as jfxc]
toydb.units))

(defrecord Circle [])

(defmethod print-method Circle [c, ^java.io.Writer writer]
  ;; Writes #toydb.shapes.Circle{:key1 val1, :key2 val2} without line-breaks
  (.write writer (str "#"
  (pr-str Circle)
  (pr-str (into {} c)

(defmethod print-dup Circle [c, ^java.io.Writer writer]
  ;; Writes #Circle{:key1 val1, :key val2} without line-breaks
  (.write writer "#Circle")
  (print-method (into {} c) writer))


(defmethod clojure.pprint/simple-dispatch Circle [c]
  ;; this is copied with minor modification from
  ;;  
https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/dispatch.clj
  ;; It seems like overkill to redefine it just to add classname at the 
beginning  
(let [amap (into {} c)]
(if clojure.core/*print-dup*
  (.write ^java.io.Writer *out* "#Circle")
  (.write ^java.io.Writer *out* (pr-str Circle))) ;; gets 
#namespace.classname
(clojure.pprint/pprint-logical-block
 :prefix "{" :suffix "}"
 (clojure.pprint/print-length-loop
  [aseq (seq amap)]
  (when aseq
(clojure.pprint/pprint-logical-block
 (clojure.pprint/write-out (ffirst aseq))
 (.write ^java.io.Writer *out* " ")
 (clojure.pprint/pprint-newline :linear)
;;  *current-length* is private to pprint-base
;;(set! *current-length* 0) ; always print both parts of the [k v] pair
 (clojure.pprint/write-out (fnext (first aseq
(when (next aseq)
      (.write ^java.io.Writer *out* ", ")
  (clojure.pprint/pprint-newline :linear)
  (recur (next aseq

























-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: need help on `pprint/write` code with better readability

[jiyinyiyong]

Cool library! But i just changed to fipp this morning. I think I will try
it much later. fipp is really fast that it succeeded clojure.pprint/write.

On Mon, Oct 24, 2016 at 4:36 PM Thomas Heller  wrote:

> Try https://github.com/weavejester/cljfmt
>
> It is specifically written for clj code and not general pprinter.
>
> /thomas
>
> On Sunday, October 23, 2016 at 1:28:23 PM UTC+2, Jiyin Yiyong wrote:
>
> I'm using `write` function to generate code very heavily. But small part
> of the code are hard to read.
> So I digged into the options and increased `right-margin` to make it a
> little better. Here's the changes:
>
>
> https://github.com/Cirru/sepal.clj/commit/e65e2d3cac8a5c5537716acd12cc475712ab6f66
>
>
> https://github.com/Quamolit/quamolit/commit/1d2e2a579a3b6741109223faa88c84157035577f
>
> But it turned out the algorithm is doing layout like always appending code
> in a line, until it reaches right margin.
> So if `right-margin` is too big, all the code are in a single line, which
> is hard to read.
> if `right-margin` is too small, then all the code in a column, which is
> also hard to read.
> I think it's not smart enough to make all of my code readable enough, but
> majority of that is fine.
>
> Is there any solution to improvement the readability at this moment?
> Especially for such scenarios:
>
>
> https://github.com/Quamolit/quamolit/blob/master/src/quamolit/render/expand.cljs#L102
>
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ZB-nSiFH3uw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: need help on `pprint/write` code with better readability

[Thomas Heller]

Try https://github.com/weavejester/cljfmt 

It is specifically written for clj code and not general pprinter.

/thomas

On Sunday, October 23, 2016 at 1:28:23 PM UTC+2, Jiyin Yiyong wrote:
>
> I'm using `write` function to generate code very heavily. But small part 
> of the code are hard to read.
> So I digged into the options and increased `right-margin` to make it a 
> little better. Here's the changes:
>
>
> https://github.com/Cirru/sepal.clj/commit/e65e2d3cac8a5c5537716acd12cc475712ab6f66
>
>
> https://github.com/Quamolit/quamolit/commit/1d2e2a579a3b6741109223faa88c84157035577f
>
> But it turned out the algorithm is doing layout like always appending code 
> in a line, until it reaches right margin.
> So if `right-margin` is too big, all the code are in a single line, which 
> is hard to read.
> if `right-margin` is too small, then all the code in a column, which is 
> also hard to read.
> I think it's not smart enough to make all of my code readable enough, but 
> majority of that is fine.
>
> Is there any solution to improvement the readability at this moment?
> Especially for such scenarios:
>
>
> https://github.com/Quamolit/quamolit/blob/master/src/quamolit/render/expand.cljs#L102
>
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: need help on `pprint/write` code with better readability

[jiyinyiyong]

What does miser-width mean since you set it to 60?

On Mon, Oct 24, 2016 at 3:08 AM Alex Miller  wrote:

> Try something like this:
>
> (require '[clojure.pprint :as pprint])
> (defn print-code [o]
>   (binding [pprint/*print-right-margin* 100
> pprint/*print-miser-width* 60]
> (pprint/with-pprint-dispatch pprint/code-dispatch
>   (pprint/pprint o
>
> Or one of the "pretty printer" libraries like fipp or zprint.
>
>
> On Sunday, October 23, 2016 at 6:28:23 AM UTC-5, Jiyin Yiyong wrote:
>
> I'm using `write` function to generate code very heavily. But small part
> of the code are hard to read.
> So I digged into the options and increased `right-margin` to make it a
> little better. Here's the changes:
>
>
> https://github.com/Cirru/sepal.clj/commit/e65e2d3cac8a5c5537716acd12cc475712ab6f66
>
>
> https://github.com/Quamolit/quamolit/commit/1d2e2a579a3b6741109223faa88c84157035577f
>
> But it turned out the algorithm is doing layout like always appending code
> in a line, until it reaches right margin.
> So if `right-margin` is too big, all the code are in a single line, which
> is hard to read.
> if `right-margin` is too small, then all the code in a column, which is
> also hard to read.
> I think it's not smart enough to make all of my code readable enough, but
> majority of that is fine.
>
> Is there any solution to improvement the readability at this moment?
> Especially for such scenarios:
>
>
> https://github.com/Quamolit/quamolit/blob/master/src/quamolit/render/expand.cljs#L102
>
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ZB-nSiFH3uw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: need help on `pprint/write` code with better readability

[Alex Miller]

Try something like this:

(require '[clojure.pprint :as pprint])
(defn print-code [o]
  (binding [pprint/*print-right-margin* 100
    pprint/*print-miser-width* 60]
(pprint/with-pprint-dispatch pprint/code-dispatch
  (pprint/pprint o

Or one of the "pretty printer" libraries like fipp or zprint.


On Sunday, October 23, 2016 at 6:28:23 AM UTC-5, Jiyin Yiyong wrote:
>
> I'm using `write` function to generate code very heavily. But small part 
> of the code are hard to read.
> So I digged into the options and increased `right-margin` to make it a 
> little better. Here's the changes:
>
>
> https://github.com/Cirru/sepal.clj/commit/e65e2d3cac8a5c5537716acd12cc475712ab6f66
>
>
> https://github.com/Quamolit/quamolit/commit/1d2e2a579a3b6741109223faa88c84157035577f
>
> But it turned out the algorithm is doing layout like always appending code 
> in a line, until it reaches right margin.
> So if `right-margin` is too big, all the code are in a single line, which 
> is hard to read.
> if `right-margin` is too small, then all the code in a column, which is 
> also hard to read.
> I think it's not smart enough to make all of my code readable enough, but 
> majority of that is fine.
>
> Is there any solution to improvement the readability at this moment?
> Especially for such scenarios:
>
>
> https://github.com/Quamolit/quamolit/blob/master/src/quamolit/render/expand.cljs#L102
>
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

need help on `pprint/write` code with better readability

[Jiyin Yiyong]

I'm using `write` function to generate code very heavily. But small part of 
the code are hard to read.
So I digged into the options and increased `right-margin` to make it a 
little better. Here's the changes:

https://github.com/Cirru/sepal.clj/commit/e65e2d3cac8a5c5537716acd12cc475712ab6f66

https://github.com/Quamolit/quamolit/commit/1d2e2a579a3b6741109223faa88c84157035577f

But it turned out the algorithm is doing layout like always appending code 
in a line, until it reaches right margin.
So if `right-margin` is too big, all the code are in a single line, which 
is hard to read.
if `right-margin` is too small, then all the code in a column, which is 
also hard to read.
I think it's not smart enough to make all of my code readable enough, but 
majority of that is fine.

Is there any solution to improvement the readability at this moment?
Especially for such scenarios:

https://github.com/Quamolit/quamolit/blob/master/src/quamolit/render/expand.cljs#L102


Thanks.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Ultra 0.2.1 - pprint-source, and playing nicely with CIDER

[W. David Jarvis]

*Ultra: a Leiningen plugin for a superior development environment.*
Release 0.2.1 comes with two changes - one feature, one (major) bugfix.


*First, the feature: pprint-source*
Ultra now has a function for pretty-printing source at the REPL - like 
`source`, but nice looking. At the moment it's squirreled away in 
`ultra.repl/pprint-source` since it uses `read-string`, which is unsafe. At 
some point I might hook it into clojure.repl/source (since - as far as the 
unsafeness goes - you'd already have to have the code in question on your 
classpath), but I'm still weighing the pros and cons there.


*Second, the bugfix: playing nicely with CIDER*
Ultra's been responsible for an unfortunate nREPL middleware ordering bug 
ever since it was open sourced. The effect of this bug (documented here: 
https://github.com/clojure-emacs/cider/issues/961) was to really screw up a 
lot of the CIDER middleware. This latest release forces the nREPL 
middleware Ultra depends on to load first, which gets rid of the problem. 

<3 to the emacs community.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving pprint behavior for anonymous functions

[Matthew DeVore]

Greg's is a nice and clean solution for the data visualization problem, 
assuming you're only going to use partials.

I hacked together a solution to support functions with equality semantics, 
if anyone is interested. It doesn't support anonymous functions or 
closures, but doing that would require some advanced macro magic and I 
don't want to invest the time in that now. Below is an example of usage - 
the source is on my 
Github
.

(defnv adder [value] [another-num]
  (+ value another-num))

(defnv exclaimer [bangs mark] [phrase]
  (apply str phrase (repeat bangs mark)))

(def adder-4 (adder 4))
(def adder-0 (adder 0))
(def exclaimer-?? (exclaimer 2 "?"))

(deftest test-defnv-equality
  (is (= (adder 1) (adder 1)))
  (is (not= (exclaimer 2 "!") exclaimer-??)))

(deftest test-defnv-invocation
  (is (= 4 (adder-4 0)))
  (is (= 44 (adder-0 44)))
  (is (= 55 (adder-4 51)))
  (is (= "Hello??" (exclaimer-?? "Hello"

(deftest test-defnv-print-method
  (are [expected vfn]
   (let [w (new java.io.StringWriter)]
 (print-method vfn w)
 (= expected (str w)))
   "(adder 0)" adder-0
   "(adder 4)" adder-4
   "(exclaimer 2 \"?\")" exclaimer-??))


在 2014年4月26日星期六UTC-7上午5时27分37秒，Greg D写道：
>
> Simpler yet using metadata:
> (ns example.ppfn)
>
> (defn print-pf [pf]
>   (if-let [ppf (::ppf (meta pf))] ppf pf))
>
> (defmacro partial* [& args]
>   `(let [m#  (pr-str '(partial* ~@args))
>  pf# (with-meta (partial ~@args) {::ppf m#})]
>  (defmethod print-method (class pf#) [o# w#] (print-simple 
> (example.ppfn/print-pf o#) w#))
>  pf#))
>
> In use:
> user=> (def p1 (partial* + 1))
> #'user/p1
> user=> (p1 5)
> 6
> user=> p1
> (example.ppfn/partial* + 1)
> user=> (def comma-join (partial* clojure.string/join ", "))
> #'user/comma-join
> user=> (comma-join ['a 'b 'c])
> "a, b, c"
> user=> comma-join
> (example.ppfn/partial* clojure.string/join ", ")
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving pprint behavior for anonymous functions

[Greg D]

Simpler yet using metadata:
(ns example.ppfn)

(defn print-pf [pf]
  (if-let [ppf (::ppf (meta pf))] ppf pf))

(defmacro partial* [& args]
  `(let [m#  (pr-str '(partial* ~@args))
 pf# (with-meta (partial ~@args) {::ppf m#})]
 (defmethod print-method (class pf#) [o# w#] (print-simple 
(example.ppfn/print-pf o#) w#))
 pf#))

In use:
user=> (def p1 (partial* + 1))
#'user/p1
user=> (p1 5)
6
user=> p1
(example.ppfn/partial* + 1)
user=> (def comma-join (partial* clojure.string/join ", "))
#'user/comma-join
user=> (comma-join ['a 'b 'c])
"a, b, c"
user=> comma-join
(example.ppfn/partial* clojure.string/join ", ")

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving pprint behavior for anonymous functions

[Matthew DeVore]

在 2014年4月25日星期五UTC-7下午12时16分22秒，Alex Miller写道：
>
>
> On Friday, April 25, 2014 1:23:49 PM UTC-5, Matthew DeVore wrote:
>>
>> Thanks for pointing out the ticket, but based on the Description, it 
>> falls short of what I need. It doesn't have any additional information that 
>> I can't deduce from looking at the code, in other words, the value of the 
>> items in the closures. So while it makes toString prettier, it's not 
>> informative.
>>
>
> That ticket is not at an end state - it could conceivably be updated to 
> include additional information for anonymous functions. I am suggesting 
> that as a place you could contribute. I do not know what level of changes 
> would be acceptable to Rich in this area. I think I can safely guess that 
> any change that made Clojure slower would not be considered in mainline 
> Clojure (but might be a candidate for some developer-friendly alternate 
> build, which is a possibility). 
>
Good point about the performance concern. It will definitely create more 
byte-code for every anonymous function, so it may not be wise to make it 
the default behavior.

I'm starting to think that I can just implement this with some macro magic 
(i.e. fn*). I just need to figure out how to determine what symbols inside 
an fn* body are arguments, and which are not (maybe using symbol 
metadata?). After that, reify a class that is an AFunction but with an 
extra method to get the closure map. Finally, just add the proper hooks for 
pprint and print-method.
 

>  
>
>> About impurity - it depends on where the impurity comes from. 
>>
>
> Functions in Clojure are not values. In languages like Haskell, it may be 
> possible to leverage reasoning around substitution and pure functions but 
> Clojure has no way to even determine that it is in such a case. If you want 
> to compare functions, then you should describe the invocation with Clojure 
> data so it can be compared like any other data and defer turning it into a 
> function invocation to the point where that needs to occur. 
>
The only assumption that has to be made to treat a function as a value is 
what about that function is part of the value. I'm arguing that the lexical 
location of the function in code, and the values of all the closured 
symbols tell you everything about the function that can be otherwise 
observed by invoking it, so that is all you need to compose its value. If a 
function is first-class, why can it not be a value as well? Considering 
them to not be non-value seems arbitrary and complex.

When using dynamic languages, I like APIs with fewer and shorter words. It 
leaves less room for typos and requires less memorization. Why force people 
to convert a value to a function when one thing can be both?

An example of when I wanted to do this was when I wrote a function to read 
a directory listing (tree object) from a Git database. It returned a 
sequence of vectors that look like this:
["4" "filename.txt" "SHA1HASH"]

The first item is the object type which identifies it as a regular file. 
Now what if I want to read filename.txt? I need info about the repo 
(location on disk), the file type ("4") and the hash. In the strategy 
you describe, I'll have to do this:

(def repo (comment this is defined elsewhere))

(for [[type name hash] (read-tree repo tree-hash)
  :when (= name "filename.txt")]
  (read-object repo type hash))

If I decided to return a function from read-tree, I have a simpler API:

(for [[_ name _ read-obj-fn] (read-tree repo tree-hash)
  :when (= name "filename.txt")]
  (read-obj-fn))

I like the second one because I have fewer functions to memorize, and it is 
less error prone because I'm never going to pass the wrong repo or type to 
read-obj-fn, whereas I may do it when I call read-object. If I had value 
semantics for functions also, I would be able to unit test this very 
elegantly, because I can just do:

(is (= (read-tree repo hash)
  [["4" "filename.txt" "SHA1HASH" (new-read-obj-fn repo "4" 
"SHA1HASH")]
   ...])

As long as (new-read-obj-fn) is used by the app code as well as the test 
case to create the reader function.

 
>
>> Is it from something like an (atom) value in the closure, that changes 
>> when you call the function? In that case, the functions won't be equal 
>> because (= (atom 0) (atom 0)) is false, as it should be. 
>>
>
>> Is it from something where the equality changes based on the state of the 
>> object, such as a mutable HashMap in the closure? In that case, the 
>> equality of the function will follow that of underlying Java objects: the 
>> functions are equal when they are interchangeable, but unequal when their 
&

Re: Improving pprint behavior for anonymous functions

[Greg D]

The code below accounts for partials of the same arity.  However, there 
might be a better way to do this with clojure.reflect:
(defn print-partial [a-fn]
  (let [c  (class a-fn)
fields (into {} (->> c .getDeclaredFields
 (map #(vector (.getName %)
   (do (.setAccessible % true)
   (.get % a-fn))
f  (get fields "f")
fname  (loop [[ns & namespaces] (all-ns)]
 (let [nsmap (into {} (map #(try (vector (deref (second %)) 
(first %))
 (catch Exception e
   [::e nil]))
   (ns-publics ns)))]
   (if-let [fname (get nsmap f)]
 #_(symbol (str ns) fname)
 (str (ns-name ns) "/" fname)
 (if (empty? namespaces)
   f
   (recur namespaces)
args   (loop [args ""
  arg-num  1]
 (if-let [arg (get fields (str "arg" arg-num))]
   (recur (str args " " (pr-str arg)) (inc arg-num))
   args))]
(str "(partial " fname args ")")))

(defmacro partial* [fname arg0 & args]
  `(let [pf#  (partial ~fname ~arg0 ~@args)
 cpf# (class pf#)]
 (defmethod print-method cpf# [o# w#]
   (print-simple (print-partial o#) w#))
 pf#))

Trying out:
(def p6 (partial* + 1 2 3))
#'user/p6
user=> p6
(partial clojure.core/+ 1 2 3)
user=> (def t7 (partial* * 1 1 7))
#'user/t7
user=> t7
(partial clojure.core/* 1 1 7)
user=> p6
(partial clojure.core/+ 1 2 3)
user=> (def comma-join (partial* clojure.string/join ", "))
#'user/comma-join
user=> comma-join
(partial clojure.string/join ", ")
user=> (p6 100)
106
user=> (t7 5)
35
user=> (comma-join ['a 'b 'c])
"a, b, c"





On Friday, April 25, 2014 2:55:23 PM UTC-7, Greg D wrote:
>
> Got it. The macro, as is, will displace the print method for the same 
> arity.
>
> On Friday, April 25, 2014 2:50:34 PM UTC-7, Gary Trakhman wrote:
>>
>> Ah, I think I was mistaken in a detail, but generally correct.  Try it 
>> with two partials of the same arity.
>>
>>
>> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2460
>>
>>
>> On Fri, Apr 25, 2014 at 5:47 PM, Greg D  wrote:
>>
>>> I guess I don't understand the problem, or what is meant by "different 
>>> classes".  A counter-example would be helpful.
>>>
>>> Further transcript using the macro:
>>> (def p6 (partial* + 1 2 3))
>>> #'user/p6
>>> user=> (class p6)
>>> clojure.core$partial$fn__4194
>>> user=> (def p10 (partial* + 1 2 3 4))
>>> #'user/p10
>>> user=> (class p10)
>>> clojure.core$partial$fn__4196
>>>
>>> user=> p6
>>> (partial + 1 2 3)
>>> user=> p10
>>> (partial + 1 2 3 4)
>>> user=> (p6 100)
>>> 106
>>> user=> (p10 100)
>>> 110
>>>
>>> On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>>>
 That's not going to work, all the return classes of partial are the 
 same class.


 On Fri, Apr 25, 2014 at 5:26 PM, Greg D  wrote:

> I don't know if this is considered good Clojure, but you could define 
> a print-method within a macro to set up the normal string representation 
> for the partial function:
> (defmacro partial* [fname arg0 & args]
>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>  cpf# (class pf#)]
>  (defmethod print-method cpf# [o# w#]
>(if (nil? '~args)
>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) 
> ")") w#)
>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) 
> ~@(map #(str " " (pr-str %)) args) ")") w#)))
>  pf#))
>
> A transcript of some quick examples:
> user=> (def p6 (partial* + 1 2 3))
> #'user/p6
> user=> p6
> (partial + 1 2 3)
> user=> (p6 7)
> 13
> user=> (def re-find-foo (partial* re-find #"foo"))
> #'user/re-find-foo
> user=> re-find-foo
> (partial re-find #"foo")
> user=> (re-find-foo "abcdefooghi")
> "foo"
>
>
> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>>
>> Hi,
>>
>> There has been one thing bugging me for a long time that seems worth 
>> it to fix, and I was wondering if anyone else has had the same problem. 
>> I 
>> have enjoyed using Clojure's REPL and embracing a Clojure-style data 
>> model 
>> for my app, where everything is a glorified map or vector and there are 
>> no 
>> private fields. I even have a simple dump feature that tells me the 
>> entire 
>> state of my app  that was 
>> ridiculously easy to implement, and that takes advantage of the lack of 
>> black box data structures.
>>
>> One thing that doesn't really fit in this paradigm is (ironical

Re: Improving pprint behavior for anonymous functions

[Greg D]

Got it. The macro, as is, will displace the print method for the same arity.

On Friday, April 25, 2014 2:50:34 PM UTC-7, Gary Trakhman wrote:
>
> Ah, I think I was mistaken in a detail, but generally correct.  Try it 
> with two partials of the same arity.
>
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2460
>
>
> On Fri, Apr 25, 2014 at 5:47 PM, Greg D 
> > wrote:
>
>> I guess I don't understand the problem, or what is meant by "different 
>> classes".  A counter-example would be helpful.
>>
>> Further transcript using the macro:
>> (def p6 (partial* + 1 2 3))
>> #'user/p6
>> user=> (class p6)
>> clojure.core$partial$fn__4194
>> user=> (def p10 (partial* + 1 2 3 4))
>> #'user/p10
>> user=> (class p10)
>> clojure.core$partial$fn__4196
>>
>> user=> p6
>> (partial + 1 2 3)
>> user=> p10
>> (partial + 1 2 3 4)
>> user=> (p6 100)
>> 106
>> user=> (p10 100)
>> 110
>>
>> On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>>
>>> That's not going to work, all the return classes of partial are the same 
>>> class.
>>>
>>>
>>> On Fri, Apr 25, 2014 at 5:26 PM, Greg D  wrote:
>>>
 I don't know if this is considered good Clojure, but you could define a 
 print-method within a macro to set up the normal string representation for 
 the partial function:
 (defmacro partial* [fname arg0 & args]
   `(let [pf#  (partial ~fname ~arg0 ~@args)
  cpf# (class pf#)]
  (defmethod print-method cpf# [o# w#]
(if (nil? '~args)
  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") 
 w#)
  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) 
 ~@(map #(str " " (pr-str %)) args) ")") w#)))
  pf#))

 A transcript of some quick examples:
 user=> (def p6 (partial* + 1 2 3))
 #'user/p6
 user=> p6
 (partial + 1 2 3)
 user=> (p6 7)
 13
 user=> (def re-find-foo (partial* re-find #"foo"))
 #'user/re-find-foo
 user=> re-find-foo
 (partial re-find #"foo")
 user=> (re-find-foo "abcdefooghi")
 "foo"


 On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>
> Hi,
>
> There has been one thing bugging me for a long time that seems worth 
> it to fix, and I was wondering if anyone else has had the same problem. I 
> have enjoyed using Clojure's REPL and embracing a Clojure-style data 
> model 
> for my app, where everything is a glorified map or vector and there are 
> no 
> private fields. I even have a simple dump feature that tells me the 
> entire 
> state of my app  that was 
> ridiculously easy to implement, and that takes advantage of the lack of 
> black box data structures.
>
> One thing that doesn't really fit in this paradigm is (ironically) 
> anonymous functions with closures. For instance, (partial + 42) returns 
> an 
> anonymous function, and in the REPL or an app dump, it looks hideous:
> #
>
> So I've avoided anonymous functions in my app except when they exist 
> transiently, and don't appear in the dump (for instance, in (map #(str % 
> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
> function practically. The best solution I've come up with is to transform 
> anonymous functions when preparing the application dump. (See the 
> implementation)
>  
> This makes (partial + 42) look like this:
>
> {:fn-class clojure.core$partial$fn__4228,
>  "arg1" 42,
>  "f" {:fn-class clojure.core$_PLUS_}}
>
> Which isn't great (I'd like to have filenames and line numbers for 
> each anon fn, and a nicer name for clojure.core/+), but it's a big 
> improvement. The function's JVM class and the closured values are 
> revealed. 
> It would be nice to implement this natively. Having only passing 
> familiarity with the Clojure code base, to solve it I think one could:
>
>- give anonymous functions a .getClosure method which creates a 
>view of the closure on-demand
>- (optional) change their .toString implementation to include this 
>information
>- add logic to clojure.pprint to use the .getClosure method (I 
>guess "(defmethod clojure.pprint/simple-dispatch 
> clojure.lang.AFunction 
>etc...)" ?) 
>
> Another feature that would go nicely with this is smarter equality 
> semantics for anonymous functions, so that any two anonymous functions 
> generated at the same point in code with equal closures are equal. This 
> means if I have a function like this:
>
> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>
> then the following would be true: (= (exclaimer 10) (exclaimer 10)), 
> making functio

Re: Improving pprint behavior for anonymous functions

[Gary Trakhman]

user> (def a (partial* + 1 2 3))
#'user/a

user> a
(partial + 1 2 3)

user> (def b (partial* + 1 2 5))
#'user/b

user> b
(partial + 1 2 5)

user> a
(partial + 1 2 5)



On Fri, Apr 25, 2014 at 5:51 PM, Greg D  wrote:

> I guess I don't understand the problem, or what is meant by "all the
> return classes of partial are the same class".  A counter-example would be
> helpful.
>
>
> Further transcript using the macro:
> user=> (def p6 (partial* + 1 2 3))
> #'user/p6
> user=> (class p6)
> clojure.core$partial$fn__4194
> user=> (def p10 (partial* + 1 2 3 4))
> #'user/p10
> user=> (class p10)
> clojure.core$partial$fn__4196
> user=> p6
> (partial + 1 2 3)
> user=> p10
> (partial + 1 2 3 4)
> user=> (p6 100)
> 106
> user=> (p10 100)
> 110
>
> On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>
>> That's not going to work, all the return classes of partial are the same
>> class.
>>
>>
>> On Fri, Apr 25, 2014 at 5:26 PM, Greg D  wrote:
>>
>>> I don't know if this is considered good Clojure, but you could define a
>>> print-method within a macro to set up the normal string representation for
>>> the partial function:
>>> (defmacro partial* [fname arg0 & args]
>>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>>  cpf# (class pf#)]
>>>  (defmethod print-method cpf# [o# w#]
>>>(if (nil? '~args)
>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")")
>>> w#)
>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0)
>>> ~@(map #(str " " (pr-str %)) args) ")") w#)))
>>>  pf#))
>>>
>>> A transcript of some quick examples:
>>> user=> (def p6 (partial* + 1 2 3))
>>> #'user/p6
>>> user=> p6
>>> (partial + 1 2 3)
>>> user=> (p6 7)
>>> 13
>>> user=> (def re-find-foo (partial* re-find #"foo"))
>>> #'user/re-find-foo
>>> user=> re-find-foo
>>> (partial re-find #"foo")
>>> user=> (re-find-foo "abcdefooghi")
>>> "foo"
>>>
>>>
>>> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:

 Hi,

 There has been one thing bugging me for a long time that seems worth it
 to fix, and I was wondering if anyone else has had the same problem. I have
 enjoyed using Clojure's REPL and embracing a Clojure-style data model for
 my app, where everything is a glorified map or vector and there are no
 private fields. I even have a simple dump feature that tells me the entire
 state of my app  that was
 ridiculously easy to implement, and that takes advantage of the lack of
 black box data structures.

 One thing that doesn't really fit in this paradigm is (ironically)
 anonymous functions with closures. For instance, (partial + 42) returns an
 anonymous function, and in the REPL or an app dump, it looks hideous:
 #

 So I've avoided anonymous functions in my app except when they exist
 transiently, and don't appear in the dump (for instance, in (map #(str %
 "!") foo)). But sometimes I just can't avoid a long-lived anonymous
 function practically. The best solution I've come up with is to transform
 anonymous functions when preparing the application dump. (See the
 implementation)
 This makes (partial + 42) look like this:

 {:fn-class clojure.core$partial$fn__4228,
  "arg1" 42,
  "f" {:fn-class clojure.core$_PLUS_}}

 Which isn't great (I'd like to have filenames and line numbers for each
 anon fn, and a nicer name for clojure.core/+), but it's a big improvement.
 The function's JVM class and the closured values are revealed. It would be
 nice to implement this natively. Having only passing familiarity with the
 Clojure code base, to solve it I think one could:

- give anonymous functions a .getClosure method which creates a
view of the closure on-demand
- (optional) change their .toString implementation to include this
information
- add logic to clojure.pprint to use the .getClosure method (I
guess "(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction
etc...)" ?)

 Another feature that would go nicely with this is smarter equality
 semantics for anonymous functions, so that any two anonymous functions
 generated at the same point in code with equal closures are equal. This
 means if I have a function like this:

 (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))

 then the following would be true: (= (exclaimer 10) (exclaimer 10)),
 making functions behave a lot more like values. I would love to have this
 particular feature too, although I'm having trouble coming up with a
 non-contrived example.

 I'd like to hear some thoughts on this. Thanks!

 Matt



  --
>>> You received this message because you are subscribed to the Google
>>> G

Re: Improving pprint behavior for anonymous functions

[Greg D]

I guess I don't understand the problem, or what is meant by "all the return 
classes of partial are the same class".  A counter-example would be helpful.

Further transcript using the macro:
user=> (def p6 (partial* + 1 2 3))
#'user/p6
user=> (class p6)
clojure.core$partial$fn__4194
user=> (def p10 (partial* + 1 2 3 4))
#'user/p10
user=> (class p10)
clojure.core$partial$fn__4196
user=> p6
(partial + 1 2 3)
user=> p10
(partial + 1 2 3 4)
user=> (p6 100)
106
user=> (p10 100)
110

On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>
> That's not going to work, all the return classes of partial are the same 
> class.
>
>
> On Fri, Apr 25, 2014 at 5:26 PM, Greg D 
> > wrote:
>
>> I don't know if this is considered good Clojure, but you could define a 
>> print-method within a macro to set up the normal string representation for 
>> the partial function:
>> (defmacro partial* [fname arg0 & args]
>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>  cpf# (class pf#)]
>>  (defmethod print-method cpf# [o# w#]
>>(if (nil? '~args)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") 
>> w#)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ~@(map 
>> #(str " " (pr-str %)) args) ")") w#)))
>>  pf#))
>>
>> A transcript of some quick examples:
>> user=> (def p6 (partial* + 1 2 3))
>> #'user/p6
>> user=> p6
>> (partial + 1 2 3)
>> user=> (p6 7)
>> 13
>> user=> (def re-find-foo (partial* re-find #"foo"))
>> #'user/re-find-foo
>> user=> re-find-foo
>> (partial re-find #"foo")
>> user=> (re-find-foo "abcdefooghi")
>> "foo"
>>
>>
>> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>>>
>>> Hi,
>>>
>>> There has been one thing bugging me for a long time that seems worth it 
>>> to fix, and I was wondering if anyone else has had the same problem. I have 
>>> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
>>> my app, where everything is a glorified map or vector and there are no 
>>> private fields. I even have a simple dump feature that tells me the entire 
>>> state of my app  that was 
>>> ridiculously easy to implement, and that takes advantage of the lack of 
>>> black box data structures.
>>>
>>> One thing that doesn't really fit in this paradigm is (ironically) 
>>> anonymous functions with closures. For instance, (partial + 42) returns an 
>>> anonymous function, and in the REPL or an app dump, it looks hideous:
>>> #
>>>
>>> So I've avoided anonymous functions in my app except when they exist 
>>> transiently, and don't appear in the dump (for instance, in (map #(str % 
>>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
>>> function practically. The best solution I've come up with is to transform 
>>> anonymous functions when preparing the application dump. (See the 
>>> implementation)
>>>  
>>> This makes (partial + 42) look like this:
>>>
>>> {:fn-class clojure.core$partial$fn__4228,
>>>  "arg1" 42,
>>>  "f" {:fn-class clojure.core$_PLUS_}}
>>>
>>> Which isn't great (I'd like to have filenames and line numbers for each 
>>> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
>>> The function's JVM class and the closured values are revealed. It would be 
>>> nice to implement this natively. Having only passing familiarity with the 
>>> Clojure code base, to solve it I think one could:
>>>
>>>- give anonymous functions a .getClosure method which creates a view 
>>>of the closure on-demand
>>>- (optional) change their .toString implementation to include this 
>>>information
>>>- add logic to clojure.pprint to use the .getClosure method (I guess 
>>>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction 
>>> etc...)" 
>>>?) 
>>>
>>> Another feature that would go nicely with this is smarter equality 
>>> semantics for anonymous functions, so that any two anonymous functions 
>>> generated at the same point in code with equal closures are equal. This 
>>> means if I have a function like this:
>>>
>>> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>>>
>>> then the following would be true: (= (exclaimer 10) (exclaimer 10)), 
>>> making functions behave a lot more like values. I would love to have this 
>>> particular feature too, although I'm having trouble coming up with a 
>>> non-contrived example.
>>>
>>> I'd like to hear some thoughts on this. Thanks!
>>>
>>> Matt
>>>
>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> htt

Re: Improving pprint behavior for anonymous functions

[Gary Trakhman]

Ah, I think I was mistaken in a detail, but generally correct.  Try it with
two partials of the same arity.

https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2460


On Fri, Apr 25, 2014 at 5:47 PM, Greg D  wrote:

> I guess I don't understand the problem, or what is meant by "different
> classes".  A counter-example would be helpful.
>
> Further transcript using the macro:
> (def p6 (partial* + 1 2 3))
> #'user/p6
> user=> (class p6)
> clojure.core$partial$fn__4194
> user=> (def p10 (partial* + 1 2 3 4))
> #'user/p10
> user=> (class p10)
> clojure.core$partial$fn__4196
>
> user=> p6
> (partial + 1 2 3)
> user=> p10
> (partial + 1 2 3 4)
> user=> (p6 100)
> 106
> user=> (p10 100)
> 110
>
> On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>
>> That's not going to work, all the return classes of partial are the same
>> class.
>>
>>
>> On Fri, Apr 25, 2014 at 5:26 PM, Greg D  wrote:
>>
>>> I don't know if this is considered good Clojure, but you could define a
>>> print-method within a macro to set up the normal string representation for
>>> the partial function:
>>> (defmacro partial* [fname arg0 & args]
>>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>>  cpf# (class pf#)]
>>>  (defmethod print-method cpf# [o# w#]
>>>(if (nil? '~args)
>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")")
>>> w#)
>>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0)
>>> ~@(map #(str " " (pr-str %)) args) ")") w#)))
>>>  pf#))
>>>
>>> A transcript of some quick examples:
>>> user=> (def p6 (partial* + 1 2 3))
>>> #'user/p6
>>> user=> p6
>>> (partial + 1 2 3)
>>> user=> (p6 7)
>>> 13
>>> user=> (def re-find-foo (partial* re-find #"foo"))
>>> #'user/re-find-foo
>>> user=> re-find-foo
>>> (partial re-find #"foo")
>>> user=> (re-find-foo "abcdefooghi")
>>> "foo"
>>>
>>>
>>> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:

 Hi,

 There has been one thing bugging me for a long time that seems worth it
 to fix, and I was wondering if anyone else has had the same problem. I have
 enjoyed using Clojure's REPL and embracing a Clojure-style data model for
 my app, where everything is a glorified map or vector and there are no
 private fields. I even have a simple dump feature that tells me the entire
 state of my app  that was
 ridiculously easy to implement, and that takes advantage of the lack of
 black box data structures.

 One thing that doesn't really fit in this paradigm is (ironically)
 anonymous functions with closures. For instance, (partial + 42) returns an
 anonymous function, and in the REPL or an app dump, it looks hideous:
 #

 So I've avoided anonymous functions in my app except when they exist
 transiently, and don't appear in the dump (for instance, in (map #(str %
 "!") foo)). But sometimes I just can't avoid a long-lived anonymous
 function practically. The best solution I've come up with is to transform
 anonymous functions when preparing the application dump. (See the
 implementation)
 This makes (partial + 42) look like this:

 {:fn-class clojure.core$partial$fn__4228,
  "arg1" 42,
  "f" {:fn-class clojure.core$_PLUS_}}

 Which isn't great (I'd like to have filenames and line numbers for each
 anon fn, and a nicer name for clojure.core/+), but it's a big improvement.
 The function's JVM class and the closured values are revealed. It would be
 nice to implement this natively. Having only passing familiarity with the
 Clojure code base, to solve it I think one could:

- give anonymous functions a .getClosure method which creates a
view of the closure on-demand
- (optional) change their .toString implementation to include this
information
- add logic to clojure.pprint to use the .getClosure method (I
guess "(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction
etc...)" ?)

 Another feature that would go nicely with this is smarter equality
 semantics for anonymous functions, so that any two anonymous functions
 generated at the same point in code with equal closures are equal. This
 means if I have a function like this:

 (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))

 then the following would be true: (= (exclaimer 10) (exclaimer 10)),
 making functions behave a lot more like values. I would love to have this
 particular feature too, although I'm having trouble coming up with a
 non-contrived example.

 I'd like to hear some thoughts on this. Thanks!

 Matt



  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>

Re: Improving pprint behavior for anonymous functions

[Greg D]

I guess I don't understand the problem, or what is meant by "different 
classes".  A counter-example would be helpful.

Further transcript using the macro:
(def p6 (partial* + 1 2 3))
#'user/p6
user=> (class p6)
clojure.core$partial$fn__4194
user=> (def p10 (partial* + 1 2 3 4))
#'user/p10
user=> (class p10)
clojure.core$partial$fn__4196
user=> p6
(partial + 1 2 3)
user=> p10
(partial + 1 2 3 4)
user=> (p6 100)
106
user=> (p10 100)
110

On Friday, April 25, 2014 2:33:50 PM UTC-7, Gary Trakhman wrote:
>
> That's not going to work, all the return classes of partial are the same 
> class.
>
>
> On Fri, Apr 25, 2014 at 5:26 PM, Greg D 
> > wrote:
>
>> I don't know if this is considered good Clojure, but you could define a 
>> print-method within a macro to set up the normal string representation for 
>> the partial function:
>> (defmacro partial* [fname arg0 & args]
>>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>>  cpf# (class pf#)]
>>  (defmethod print-method cpf# [o# w#]
>>(if (nil? '~args)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") 
>> w#)
>>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ~@(map 
>> #(str " " (pr-str %)) args) ")") w#)))
>>  pf#))
>>
>> A transcript of some quick examples:
>> user=> (def p6 (partial* + 1 2 3))
>> #'user/p6
>> user=> p6
>> (partial + 1 2 3)
>> user=> (p6 7)
>> 13
>> user=> (def re-find-foo (partial* re-find #"foo"))
>> #'user/re-find-foo
>> user=> re-find-foo
>> (partial re-find #"foo")
>> user=> (re-find-foo "abcdefooghi")
>> "foo"
>>
>>
>> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>>>
>>> Hi,
>>>
>>> There has been one thing bugging me for a long time that seems worth it 
>>> to fix, and I was wondering if anyone else has had the same problem. I have 
>>> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
>>> my app, where everything is a glorified map or vector and there are no 
>>> private fields. I even have a simple dump feature that tells me the entire 
>>> state of my app  that was 
>>> ridiculously easy to implement, and that takes advantage of the lack of 
>>> black box data structures.
>>>
>>> One thing that doesn't really fit in this paradigm is (ironically) 
>>> anonymous functions with closures. For instance, (partial + 42) returns an 
>>> anonymous function, and in the REPL or an app dump, it looks hideous:
>>> #
>>>
>>> So I've avoided anonymous functions in my app except when they exist 
>>> transiently, and don't appear in the dump (for instance, in (map #(str % 
>>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
>>> function practically. The best solution I've come up with is to transform 
>>> anonymous functions when preparing the application dump. (See the 
>>> implementation)
>>>  
>>> This makes (partial + 42) look like this:
>>>
>>> {:fn-class clojure.core$partial$fn__4228,
>>>  "arg1" 42,
>>>  "f" {:fn-class clojure.core$_PLUS_}}
>>>
>>> Which isn't great (I'd like to have filenames and line numbers for each 
>>> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
>>> The function's JVM class and the closured values are revealed. It would be 
>>> nice to implement this natively. Having only passing familiarity with the 
>>> Clojure code base, to solve it I think one could:
>>>
>>>- give anonymous functions a .getClosure method which creates a view 
>>>of the closure on-demand
>>>- (optional) change their .toString implementation to include this 
>>>information
>>>- add logic to clojure.pprint to use the .getClosure method (I guess 
>>>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction 
>>> etc...)" 
>>>?) 
>>>
>>> Another feature that would go nicely with this is smarter equality 
>>> semantics for anonymous functions, so that any two anonymous functions 
>>> generated at the same point in code with equal closures are equal. This 
>>> means if I have a function like this:
>>>
>>> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>>>
>>> then the following would be true: (= (exclaimer 10) (exclaimer 10)), 
>>> making functions behave a lot more like values. I would love to have this 
>>> particular feature too, although I'm having trouble coming up with a 
>>> non-contrived example.
>>>
>>> I'd like to hear some thoughts on this. Thanks!
>>>
>>> Matt
>>>
>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en

Re: Improving pprint behavior for anonymous functions

[Gary Trakhman]

That's not going to work, all the return classes of partial are the same
class.


On Fri, Apr 25, 2014 at 5:26 PM, Greg D  wrote:

> I don't know if this is considered good Clojure, but you could define a
> print-method within a macro to set up the normal string representation for
> the partial function:
> (defmacro partial* [fname arg0 & args]
>   `(let [pf#  (partial ~fname ~arg0 ~@args)
>  cpf# (class pf#)]
>  (defmethod print-method cpf# [o# w#]
>(if (nil? '~args)
>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") w#)
>  (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ~@(map
> #(str " " (pr-str %)) args) ")") w#)))
>  pf#))
>
> A transcript of some quick examples:
> user=> (def p6 (partial* + 1 2 3))
> #'user/p6
> user=> p6
> (partial + 1 2 3)
> user=> (p6 7)
> 13
> user=> (def re-find-foo (partial* re-find #"foo"))
> #'user/re-find-foo
> user=> re-find-foo
> (partial re-find #"foo")
> user=> (re-find-foo "abcdefooghi")
> "foo"
>
>
> On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>>
>> Hi,
>>
>> There has been one thing bugging me for a long time that seems worth it
>> to fix, and I was wondering if anyone else has had the same problem. I have
>> enjoyed using Clojure's REPL and embracing a Clojure-style data model for
>> my app, where everything is a glorified map or vector and there are no
>> private fields. I even have a simple dump feature that tells me the entire
>> state of my app  that was
>> ridiculously easy to implement, and that takes advantage of the lack of
>> black box data structures.
>>
>> One thing that doesn't really fit in this paradigm is (ironically)
>> anonymous functions with closures. For instance, (partial + 42) returns an
>> anonymous function, and in the REPL or an app dump, it looks hideous:
>> #
>>
>> So I've avoided anonymous functions in my app except when they exist
>> transiently, and don't appear in the dump (for instance, in (map #(str %
>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous
>> function practically. The best solution I've come up with is to transform
>> anonymous functions when preparing the application dump. (See the
>> implementation)
>> This makes (partial + 42) look like this:
>>
>> {:fn-class clojure.core$partial$fn__4228,
>>  "arg1" 42,
>>  "f" {:fn-class clojure.core$_PLUS_}}
>>
>> Which isn't great (I'd like to have filenames and line numbers for each
>> anon fn, and a nicer name for clojure.core/+), but it's a big improvement.
>> The function's JVM class and the closured values are revealed. It would be
>> nice to implement this natively. Having only passing familiarity with the
>> Clojure code base, to solve it I think one could:
>>
>>- give anonymous functions a .getClosure method which creates a view
>>of the closure on-demand
>>- (optional) change their .toString implementation to include this
>>information
>>- add logic to clojure.pprint to use the .getClosure method (I guess
>>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction etc...)"
>>?)
>>
>> Another feature that would go nicely with this is smarter equality
>> semantics for anonymous functions, so that any two anonymous functions
>> generated at the same point in code with equal closures are equal. This
>> means if I have a function like this:
>>
>> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>>
>> then the following would be true: (= (exclaimer 10) (exclaimer 10)),
>> making functions behave a lot more like values. I would love to have this
>> particular feature too, although I'm having trouble coming up with a
>> non-contrived example.
>>
>> I'd like to hear some thoughts on this. Thanks!
>>
>> Matt
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http:

Re: Improving pprint behavior for anonymous functions

[Greg D]

I don't know if this is considered good Clojure, but you could define a 
print-method within a macro to set up the normal string representation for 
the partial function:
(defmacro partial* [fname arg0 & args]
  `(let [pf#  (partial ~fname ~arg0 ~@args)
 cpf# (class pf#)]
 (defmethod print-method cpf# [o# w#]
   (if (nil? '~args)
 (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ")") w#)
 (print-simple (str "(partial " '~fname " " (pr-str ~arg0) ~@(map 
#(str " " (pr-str %)) args) ")") w#)))
 pf#))

A transcript of some quick examples:
user=> (def p6 (partial* + 1 2 3))
#'user/p6
user=> p6
(partial + 1 2 3)
user=> (p6 7)
13
user=> (def re-find-foo (partial* re-find #"foo"))
#'user/re-find-foo
user=> re-find-foo
(partial re-find #"foo")
user=> (re-find-foo "abcdefooghi")
"foo"


On Friday, April 25, 2014 9:01:37 AM UTC-7, Matthew DeVore wrote:
>
> Hi,
>
> There has been one thing bugging me for a long time that seems worth it to 
> fix, and I was wondering if anyone else has had the same problem. I have 
> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
> my app, where everything is a glorified map or vector and there are no 
> private fields. I even have a simple dump feature that tells me the entire 
> state of my app  that was 
> ridiculously easy to implement, and that takes advantage of the lack of 
> black box data structures.
>
> One thing that doesn't really fit in this paradigm is (ironically) 
> anonymous functions with closures. For instance, (partial + 42) returns an 
> anonymous function, and in the REPL or an app dump, it looks hideous:
> #
>
> So I've avoided anonymous functions in my app except when they exist 
> transiently, and don't appear in the dump (for instance, in (map #(str % 
> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
> function practically. The best solution I've come up with is to transform 
> anonymous functions when preparing the application dump. (See the 
> implementation)
>  
> This makes (partial + 42) look like this:
>
> {:fn-class clojure.core$partial$fn__4228,
>  "arg1" 42,
>  "f" {:fn-class clojure.core$_PLUS_}}
>
> Which isn't great (I'd like to have filenames and line numbers for each 
> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
> The function's JVM class and the closured values are revealed. It would be 
> nice to implement this natively. Having only passing familiarity with the 
> Clojure code base, to solve it I think one could:
>
>- give anonymous functions a .getClosure method which creates a view 
>of the closure on-demand
>- (optional) change their .toString implementation to include this 
>information
>- add logic to clojure.pprint to use the .getClosure method (I guess 
>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction etc...)" 
>?)
>
> Another feature that would go nicely with this is smarter equality 
> semantics for anonymous functions, so that any two anonymous functions 
> generated at the same point in code with equal closures are equal. This 
> means if I have a function like this:
>
> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>
> then the following would be true: (= (exclaimer 10) (exclaimer 10)), 
> making functions behave a lot more like values. I would love to have this 
> particular feature too, although I'm having trouble coming up with a 
> non-contrived example.
>
> I'd like to hear some thoughts on this. Thanks!
>
> Matt
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving pprint behavior for anonymous functions

[Alex Miller]

On Friday, April 25, 2014 1:23:49 PM UTC-5, Matthew DeVore wrote:
>
> Thanks for pointing out the ticket, but based on the Description, it falls 
> short of what I need. It doesn't have any additional information that I 
> can't deduce from looking at the code, in other words, the value of the 
> items in the closures. So while it makes toString prettier, it's not 
> informative.
>

That ticket is not at an end state - it could conceivably be updated to 
include additional information for anonymous functions. I am suggesting 
that as a place you could contribute. I do not know what level of changes 
would be acceptable to Rich in this area. I think I can safely guess that 
any change that made Clojure slower would not be considered in mainline 
Clojure (but might be a candidate for some developer-friendly alternate 
build, which is a possibility). 
 

> About impurity - it depends on where the impurity comes from. 
>

Functions in Clojure are not values. In languages like Haskell, it may be 
possible to leverage reasoning around substitution and pure functions but 
Clojure has no way to even determine that it is in such a case. If you want 
to compare functions, then you should describe the invocation with Clojure 
data so it can be compared like any other data and defer turning it into a 
function invocation to the point where that needs to occur. 
 

> Is it from something like an (atom) value in the closure, that changes 
> when you call the function? In that case, the functions won't be equal 
> because (= (atom 0) (atom 0)) is false, as it should be. 
>

> Is it from something where the equality changes based on the state of the 
> object, such as a mutable HashMap in the closure? In that case, the 
> equality of the function will follow that of underlying Java objects: the 
> functions are equal when they are interchangeable, but unequal when their 
> states get out of sync. The equality semantics of the objects in the 
> closure are reflected in the function itself.
>
> Is the impurity coming from something in the environment, like the 
> filesystem? In that case, the two functions will be equal, since they don't 
> store the state in their closures, which makes sense, since the functions 
> are interchangeable.
>
> 在 2014年4月25日星期五UTC-7上午11时01分06秒，Alex Miller写道：
>>
>> You might be interested in this ticket (
>> http://dev.clojure.org/jira/browse/CLJ-1278)
>>  
>> of which this is perhaps one special case. 
>>
>> I don't know that I necessarily would want the equality semantics; at 
>> least in the case of impure functions the equality does not hold.
>>
>> On Friday, April 25, 2014 11:01:37 AM UTC-5, Matthew DeVore wrote:
>>>
>>> Hi,
>>>
>>> There has been one thing bugging me for a long time that seems worth it 
>>> to fix, and I was wondering if anyone else has had the same problem. I have 
>>> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
>>> my app, where everything is a glorified map or vector and there are no 
>>> private fields. I even have a simple dump feature that tells me the entire 
>>> state of my app  that was 
>>> ridiculously easy to implement, and that takes advantage of the lack of 
>>> black box data structures.
>>>
>>> One thing that doesn't really fit in this paradigm is (ironically) 
>>> anonymous functions with closures. For instance, (partial + 42) returns an 
>>> anonymous function, and in the REPL or an app dump, it looks hideous:
>>> #
>>>
>>> So I've avoided anonymous functions in my app except when they exist 
>>> transiently, and don't appear in the dump (for instance, in (map #(str % 
>>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
>>> function practically. The best solution I've come up with is to transform 
>>> anonymous functions when preparing the application dump. (See the 
>>> implementation)
>>>  
>>> This makes (partial + 42) look like this:
>>>
>>> {:fn-class clojure.core$partial$fn__4228,
>>>  "arg1" 42,
>>>  "f" {:fn-class clojure.core$_PLUS_}}
>>>
>>> Which isn't great (I'd like to have filenames and line numbers for each 
>>> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
>>> The function's JVM class and the closured values are revealed. It would be 
>>> nice to implement this natively. Having only passing familiarity with the 
>>> Clojure code base, to solve it I think one could:
>>>
>>>- give anonymous functions a .getClosure method which creates a view 
>>>of the closure on-demand
>>>- (optional) change their .toString implementation to include this 
>>>information
>>>- add logic to clojure.pprint to use the .getClosure method (I guess 
>>>"(defmethod clojure.pprint/simple-d

Re: Improving pprint behavior for anonymous functions

[Matthew DeVore]

Thanks for pointing out the ticket, but based on the Description, it falls 
short of what I need. It doesn't have any additional information that I 
can't deduce from looking at the code, in other words, the value of the 
items in the closures. So while it makes toString prettier, it's not 
informative.

About impurity - it depends on where the impurity comes from. Is it from 
something like an (atom) value in the closure, that changes when you call 
the function? In that case, the functions won't be equal because (= (atom 
0) (atom 0)) is false, as it should be.

Is it from something where the equality changes based on the state of the 
object, such as a mutable HashMap in the closure? In that case, the 
equality of the function will follow that of underlying Java objects: the 
functions are equal when they are interchangeable, but unequal when their 
states get out of sync. The equality semantics of the objects in the 
closure are reflected in the function itself.

Is the impurity coming from something in the environment, like the 
filesystem? In that case, the two functions will be equal, since they don't 
store the state in their closures, which makes sense, since the functions 
are interchangeable.

在 2014年4月25日星期五UTC-7上午11时01分06秒，Alex Miller写道：
>
> You might be interested in this ticket (
> http://dev.clojure.org/jira/browse/CLJ-1278) of which this is perhaps one 
> special case. 
>
> I don't know that I necessarily would want the equality semantics; at 
> least in the case of impure functions the equality does not hold.
>
> On Friday, April 25, 2014 11:01:37 AM UTC-5, Matthew DeVore wrote:
>>
>> Hi,
>>
>> There has been one thing bugging me for a long time that seems worth it 
>> to fix, and I was wondering if anyone else has had the same problem. I have 
>> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
>> my app, where everything is a glorified map or vector and there are no 
>> private fields. I even have a simple dump feature that tells me the entire 
>> state of my app  that was 
>> ridiculously easy to implement, and that takes advantage of the lack of 
>> black box data structures.
>>
>> One thing that doesn't really fit in this paradigm is (ironically) 
>> anonymous functions with closures. For instance, (partial + 42) returns an 
>> anonymous function, and in the REPL or an app dump, it looks hideous:
>> #
>>
>> So I've avoided anonymous functions in my app except when they exist 
>> transiently, and don't appear in the dump (for instance, in (map #(str % 
>> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
>> function practically. The best solution I've come up with is to transform 
>> anonymous functions when preparing the application dump. (See the 
>> implementation)
>>  
>> This makes (partial + 42) look like this:
>>
>> {:fn-class clojure.core$partial$fn__4228,
>>  "arg1" 42,
>>  "f" {:fn-class clojure.core$_PLUS_}}
>>
>> Which isn't great (I'd like to have filenames and line numbers for each 
>> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
>> The function's JVM class and the closured values are revealed. It would be 
>> nice to implement this natively. Having only passing familiarity with the 
>> Clojure code base, to solve it I think one could:
>>
>>- give anonymous functions a .getClosure method which creates a view 
>>of the closure on-demand
>>- (optional) change their .toString implementation to include this 
>>information
>>- add logic to clojure.pprint to use the .getClosure method (I guess 
>>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction 
>> etc...)" 
>>?)
>>
>> Another feature that would go nicely with this is smarter equality 
>> semantics for anonymous functions, so that any two anonymous functions 
>> generated at the same point in code with equal closures are equal. This 
>> means if I have a function like this:
>>
>> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>>
>> then the following would be true: (= (exclaimer 10) (exclaimer 10)), 
>> making functions behave a lot more like values. I would love to have this 
>> particular feature too, although I'm having trouble coming up with a 
>> non-contrived example.
>>
>> I'd like to hear some thoughts on this. Thanks!
>>
>> Matt
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To un

Re: Improving pprint behavior for anonymous functions

[Alex Miller]

You might be interested in this ticket 
(http://dev.clojure.org/jira/browse/CLJ-1278) of which this is perhaps one 
special case. 

I don't know that I necessarily would want the equality semantics; at least 
in the case of impure functions the equality does not hold.

On Friday, April 25, 2014 11:01:37 AM UTC-5, Matthew DeVore wrote:
>
> Hi,
>
> There has been one thing bugging me for a long time that seems worth it to 
> fix, and I was wondering if anyone else has had the same problem. I have 
> enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
> my app, where everything is a glorified map or vector and there are no 
> private fields. I even have a simple dump feature that tells me the entire 
> state of my app  that was 
> ridiculously easy to implement, and that takes advantage of the lack of 
> black box data structures.
>
> One thing that doesn't really fit in this paradigm is (ironically) 
> anonymous functions with closures. For instance, (partial + 42) returns an 
> anonymous function, and in the REPL or an app dump, it looks hideous:
> #
>
> So I've avoided anonymous functions in my app except when they exist 
> transiently, and don't appear in the dump (for instance, in (map #(str % 
> "!") foo)). But sometimes I just can't avoid a long-lived anonymous 
> function practically. The best solution I've come up with is to transform 
> anonymous functions when preparing the application dump. (See the 
> implementation)
>  
> This makes (partial + 42) look like this:
>
> {:fn-class clojure.core$partial$fn__4228,
>  "arg1" 42,
>  "f" {:fn-class clojure.core$_PLUS_}}
>
> Which isn't great (I'd like to have filenames and line numbers for each 
> anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
> The function's JVM class and the closured values are revealed. It would be 
> nice to implement this natively. Having only passing familiarity with the 
> Clojure code base, to solve it I think one could:
>
>- give anonymous functions a .getClosure method which creates a view 
>of the closure on-demand
>- (optional) change their .toString implementation to include this 
>information
>- add logic to clojure.pprint to use the .getClosure method (I guess 
>"(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction etc...)" 
>?)
>
> Another feature that would go nicely with this is smarter equality 
> semantics for anonymous functions, so that any two anonymous functions 
> generated at the same point in code with equal closures are equal. This 
> means if I have a function like this:
>
> (defn exclaimer [bangs] #(apply str % (repeat bangs "!")))
>
> then the following would be true: (= (exclaimer 10) (exclaimer 10)), 
> making functions behave a lot more like values. I would love to have this 
> particular feature too, although I'm having trouble coming up with a 
> non-contrived example.
>
> I'd like to hear some thoughts on this. Thanks!
>
> Matt
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Improving pprint behavior for anonymous functions

[Matthew DeVore]

Hi,

There has been one thing bugging me for a long time that seems worth it to 
fix, and I was wondering if anyone else has had the same problem. I have 
enjoyed using Clojure's REPL and embracing a Clojure-style data model for 
my app, where everything is a glorified map or vector and there are no 
private fields. I even have a simple dump feature that tells me the entire 
state of my app  that was ridiculously 
easy to implement, and that takes advantage of the lack of black box data 
structures.

One thing that doesn't really fit in this paradigm is (ironically) 
anonymous functions with closures. For instance, (partial + 42) returns an 
anonymous function, and in the REPL or an app dump, it looks hideous:
#

So I've avoided anonymous functions in my app except when they exist 
transiently, and don't appear in the dump (for instance, in (map #(str % 
"!") foo)). But sometimes I just can't avoid a long-lived anonymous 
function practically. The best solution I've come up with is to transform 
anonymous functions when preparing the application dump. (See the 
implementation)
 
This makes (partial + 42) look like this:

{:fn-class clojure.core$partial$fn__4228,
 "arg1" 42,
 "f" {:fn-class clojure.core$_PLUS_}}

Which isn't great (I'd like to have filenames and line numbers for each 
anon fn, and a nicer name for clojure.core/+), but it's a big improvement. 
The function's JVM class and the closured values are revealed. It would be 
nice to implement this natively. Having only passing familiarity with the 
Clojure code base, to solve it I think one could:

   - give anonymous functions a .getClosure method which creates a view of 
   the closure on-demand
   - (optional) change their .toString implementation to include this 
   information
   - add logic to clojure.pprint to use the .getClosure method (I guess 
   "(defmethod clojure.pprint/simple-dispatch clojure.lang.AFunction etc...)" 
   ?)

Another feature that would go nicely with this is smarter equality 
semantics for anonymous functions, so that any two anonymous functions 
generated at the same point in code with equal closures are equal. This 
means if I have a function like this:

(defn exclaimer [bangs] #(apply str % (repeat bangs "!")))

then the following would be true: (= (exclaimer 10) (exclaimer 10)), making 
functions behave a lot more like values. I would love to have this 
particular feature too, although I'm having trouble coming up with a 
non-contrived example.

I'd like to hear some thoughts on this. Thanks!

Matt



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: (pprint template) gives me an exception

[Gary Verhaegen]

Most probably, your template is a lazy seq and pprint forces its
evaluation, which is why the error happens at the pprint point.

On 17 April 2013 08:33, Tassilo Horn  wrote:
> larry google groups  writes:
>
>>   (println (pp/pprint template))
>
> Aside from the original problem: pprint already prints to *out* and only
> returns nil, so the code above first prints template, and then the
> println will also print the nil returned from pprint.
>
> Bye,
> Tassilo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (pprint template) gives me an exception

[Tassilo Horn]

larry google groups  writes:

>   (println (pp/pprint template))

Aside from the original problem: pprint already prints to *out* and only
returns nil, so the code above first prints template, and then the
println will also print the nil returned from pprint.

Bye,
Tassilo

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (pprint template) gives me an exception

[larry google groups]

Oh, I see. I had just changed :admin-text to hold a keyword instead of
text. I should have seen that sooner.

But I am still confused why a keyword would cause pprint to throw an
exception. And why at that point in the code, and not sooner?



On Apr 16, 10:05 am, larry google groups 
wrote:
> The function before the previously mentioned function is this:
>
> (defn add-public-text-to-top-banner-and-return-as-new-template
> [template item]
>   (println "entering add-public-text-to-top-banner-and-return-as-new-
> template")
>   (println (pp/pprint template))
>   (enlive/transform template [:#content :> :h1 :span] (enlive/content
> (:admin-text item
>
> I am not clear why this kills the template, but it seems to. Here,
> pprint works and shows the Enlive nodes. But in the next function I
> get an exception.
>
> On Apr 16, 9:59 am, larry google groups 
> wrote:
>
>
>
>
>
>
>
> > On the first pprint expression in this function, I get an exception:
>
> > (defn add-main-image-for-this-item-and-return-as-new-template
> > [template item]
>
> > (println " start of add-main-image-for-this-item-and-return-as-new-
> > template")
>
> > (println (pp/pprint template))
> >   (println "add-main-image-for-this-item-and-return-as-new-template")
> >   (let [final-template (if-not (nil? (:filename item))
> >                          (enlive/transform template [:#main-image-for-
> > this-item] (enlive/html-content (str "")))
> >                          template)]
> > (println (pp/pprint final-template))
> >       (println "  leaving add-main-image-for-this-item-and-return-as-
> > new-template")
> >     final-template))
>
> > The exception is:
>
> >  start of add-main-image-for-this-item-and-return-as-new-template
> > 2013-04-16 09:54:23.536:WARN:oejs.AbstractHttpConnection:/admin/edit/
> > planners/summer-camp3804946
> > java.lang.IllegalArgumentException: Don't know how to create ISeq
> > from: clojure.lang.Keyword
> >         at clojure.lang.RT.seqFrom(RT.java:494)
> >         at clojure.lang.RT.seq(RT.java:475)
>
> > Why would anything blow up on pprint? I thought pprint could handle
> > anything?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (pprint template) gives me an exception

[larry google groups]

The function before the previously mentioned function is this:

(defn add-public-text-to-top-banner-and-return-as-new-template
[template item]
  (println "entering add-public-text-to-top-banner-and-return-as-new-
template")
  (println (pp/pprint template))
  (enlive/transform template [:#content :> :h1 :span] (enlive/content
(:admin-text item


I am not clear why this kills the template, but it seems to. Here,
pprint works and shows the Enlive nodes. But in the next function I
get an exception.



On Apr 16, 9:59 am, larry google groups 
wrote:
> On the first pprint expression in this function, I get an exception:
>
> (defn add-main-image-for-this-item-and-return-as-new-template
> [template item]
>
> (println " start of add-main-image-for-this-item-and-return-as-new-
> template")
>
> (println (pp/pprint template))
>   (println "add-main-image-for-this-item-and-return-as-new-template")
>   (let [final-template (if-not (nil? (:filename item))
>                          (enlive/transform template [:#main-image-for-
> this-item] (enlive/html-content (str "")))
>                          template)]
> (println (pp/pprint final-template))
>       (println "  leaving add-main-image-for-this-item-and-return-as-
> new-template")
>     final-template))
>
> The exception is:
>
>  start of add-main-image-for-this-item-and-return-as-new-template
> 2013-04-16 09:54:23.536:WARN:oejs.AbstractHttpConnection:/admin/edit/
> planners/summer-camp3804946
> java.lang.IllegalArgumentException: Don't know how to create ISeq
> from: clojure.lang.Keyword
>         at clojure.lang.RT.seqFrom(RT.java:494)
>         at clojure.lang.RT.seq(RT.java:475)
>
> Why would anything blow up on pprint? I thought pprint could handle
> anything?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

(pprint template) gives me an exception

[larry google groups]

On the first pprint expression in this function, I get an exception:


(defn add-main-image-for-this-item-and-return-as-new-template
[template item]

(println " start of add-main-image-for-this-item-and-return-as-new-
template")

(println (pp/pprint template))
  (println "add-main-image-for-this-item-and-return-as-new-template")
  (let [final-template (if-not (nil? (:filename item))
 (enlive/transform template [:#main-image-for-
this-item] (enlive/html-content (str "")))
     template)]
(println (pp/pprint final-template))
  (println "  leaving add-main-image-for-this-item-and-return-as-
new-template")
final-template))


The exception is:

 start of add-main-image-for-this-item-and-return-as-new-template
2013-04-16 09:54:23.536:WARN:oejs.AbstractHttpConnection:/admin/edit/
planners/summer-camp3804946
java.lang.IllegalArgumentException: Don't know how to create ISeq
from: clojure.lang.Keyword
at clojure.lang.RT.seqFrom(RT.java:494)
at clojure.lang.RT.seq(RT.java:475)


Why would anything blow up on pprint? I thought pprint could handle
anything?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

my code blows up when I try to see it using pprint

[larry google groups]

I have a function which at this point only amounts to a print line:


(defn add-rows-of-choices-for-a-given-type-and-return-new-template 
[template item-type-as-string sequence-of-items]
  (pp/pprint sequence-of-items)
  ;; (let [inner-template-of-rows-showing-options-for-this-type-of-item 
(enlive/html-resource "templates/rows_of_options.html")
  ;;   inner-template (enlive/select 
inner-template-of-rows-showing-options-for-this-type-of-item 
[:#list_all_of_type_inner_rows_and_options])
  ;;   inner-template-transformed (enlive/transform inner-template 
[:.row_of_choices]  
  ;;(enlive/clone-for 
[one-map-of-this-type sequence-of-items]
  ;; 
 [:li :h2]
  ;; 
 (enlive/content (:public-text one-map-of-this-type))
  ;; 
 [:li.edit_button :a]
  ;; 
 (enlive/set-attr :href (str "/admin/edit/" item-type-as-string "/" 
(correct/transform-keyword-into-string (:item-name one-map-of-this-type
  ;; 
 [:li.preview_button :a]
  ;; 
 (enlive/set-attr :href (str "/admin/preview/" item-type-as-string"/" 
(correct/transform-keyword-into-string (:item-name one-map-of-this-type
  ;; 
 [:li.delete_button :a]
  ;; 
 (enlive/set-attr :href (str "/admin/delete/" item-type-as-string  "/" 
(correct/transform-keyword-into-string (:item-name one-map-of-this-type
  ;; 
 [:li.clone_button :a]
  ;; 
 (enlive/set-attr :href (str "/admin/clone/" item-type-as-string "/" 
(correct/transform-keyword-into-string (:item-name 
one-map-of-this-type))
  ;;   final-template (enlive/transform template 
[:#rows-of-choices-for-a-given-type] (enlive/content 
inner-template-transformed))]
  ;;   final-template
;; )
  )


I get this error: 


java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be 
cast to java.util.Map$Entry
at clojure.lang.APersistentMap$ValSeq.first(APersistentMap.java:174)
at clojure.lang.RT.first(RT.java:566)
at clojure.core$first.invoke(core.clj:55)
at clojure.pprint$pprint_reader_macro.invoke(dispatch.clj:50)
at clojure.pprint$pprint_list.invoke(dispatch.clj:77)
at clojure.lang.MultiFn.invoke(MultiFn.java:163)
at clojure.pprint$write_out.invoke(pprint_base.clj:194)
at clojure.pprint$pprint$fn__7359.invoke(pprint_base.clj:250)
at clojure.pprint$pprint.invoke(pprint_base.clj:248)
at clojure.pprint$pprint.invoke(pprint_base.clj:245)
at 
kiosks_clojure.admin$add_rows_of_choices_for_a_given_type_and_return_new_template.invoke(admin.clj:28)
at kiosks_clojure.admin$render_all_of_this_type.invoke(admin.clj:222)
at 
kiosks_clojure.admin$render_the_template_that_lists_all_items_of_this_type.invoke(admin.clj:234)


The function that feeds data to this function returns this:




return value from 
 transform-seq-of-items-filter-out-any-that-are-scheduled-to-be-deleted 
[{:per-page-form-cache {:per-page-banner-title "What kind of performing 
arts?", :html-input " ChooseDanceTheaterMusicAll kinds"}, 
:slides-styles " #supporting_and_explanatory_illustration { 
background-image: url('/img/camp_planner_the_sun_is_shining.png') }  ", 
:public-text "What kind of performing arts?", :multiple false, :planners-id 
:summer-camp, :item-name :performing-arts-followup, :item-image 
"camp_planner_the_sun_is_shining.png", :children-type :answers} 
{:per-page-form-cache {:per-page-banner-title "What type of camp? ", 
:html-input " ChooseAcademicArtPerforming 
ArtsSportsGeneral 
interestSpecial 
interestSpecial 
needs"}, :slides-styles " 
#supporting_and_explanatory_illustration { background-image: 
url('/img/camp_planner_the_sun_is_shining.png') }  ", :public-text "What 
type of camp? ", :multiple false, :planners-id :summer-camp, :item-name 
:what-type-of-camp-daycamp, :item-image 
"camp_planner_the_sun_is_shining.png", :children-type :answers} 
{:per-page-form-cache {:per-page-banner-title "What's your budget? ", 
:html-input " Choose$$"},
 
:slides-styles " #supporting_and_explanatory_illustration { 
background-image: url('/img/camp_planner_dollar_signs.png') }  ", 
:public-text "What's your budget? ", :multiple

Re: weird pprint behaviour ?

[Frank Siebenlist]

Thanks for catching that - I didn't even notice that I was printing the binding 
var itself… need coffee…

-FS.


On May 3, 2012, at 9:59 AM, Meikel Brandmeyer wrote:

> Hi,
> 
> Am 03.05.2012 um 18:43 schrieb Frank Siebenlist:
> 
>> user=> (pprint #'clojure.core/*print-length*)
>> #
>> nil
>> user=> (clj-ns-browser.utils/pprint-str #'clojure.core/*print-length*)
>> "#\n"
>> user=> (with-out-str (binding [*print-length* 32 *print-level* 6] (pprint 
>> #'clojure.core/*print-length*)))
>> "#\n"
>> user=> (binding [*print-length* 32 *print-level* 6] (pprint 
>> #'clojure.core/*print-length*))#
>> nil
>> user=> (binding [*print-length* 33 *print-level* 6] (pprint 
>> #'clojure.core/*print-length*))
>> #
>> nil
>> user=> 
>> 
>> 
>> It seems that the *print-length* binding-value is printed out when the 
>> var-value is nil.
> 
> Oeh. You always print *print-length* in your examples. And that is never nil, 
> because you set to 32 in your function. Did you check also other vars?
> 
> For me it seems to work.
> 
> user=> (def f nil)
> #'user/f
> user=> (binding [*print-length* 32] (clojure.pprint/pprint f))
> nil
> 
> Kind regards
> Meikel
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: weird pprint behaviour ?

[Meikel Brandmeyer]

Hi again,

Am 03.05.2012 um 18:59 schrieb Meikel Brandmeyer:

> user=> (def f nil)
> #'user/f
> user=> (binding [*print-length* 32] (clojure.pprint/pprint f))
> nil

Of course I should have printed the Var.

user=> (binding [*print-length* 32] (clojure.pprint/pprint #'f))
#

Kind regards
Meikel

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: weird pprint behaviour ?

[Meikel Brandmeyer]

Hi,

Am 03.05.2012 um 18:43 schrieb Frank Siebenlist:

> user=> (pprint #'clojure.core/*print-length*)
> #
> nil
> user=> (clj-ns-browser.utils/pprint-str #'clojure.core/*print-length*)
> "#\n"
> user=> (with-out-str (binding [*print-length* 32 *print-level* 6] (pprint 
> #'clojure.core/*print-length*)))
> "#\n"
> user=> (binding [*print-length* 32 *print-level* 6] (pprint 
> #'clojure.core/*print-length*))#
> nil
> user=> (binding [*print-length* 33 *print-level* 6] (pprint 
> #'clojure.core/*print-length*))
> #
> nil
> user=> 
> 
> 
> It seems that the *print-length* binding-value is printed out when the 
> var-value is nil.

Oeh. You always print *print-length* in your examples. And that is never nil, 
because you set to 32 in your function. Did you check also other vars?

For me it seems to work.

user=> (def f nil)
#'user/f
user=> (binding [*print-length* 32] (clojure.pprint/pprint f))
nil

Kind regards
Meikel

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

weird pprint behaviour ?

[Frank Siebenlist]

I'm using the following function to have pprint write into a string and limit 
the output:


(defn pprint-str
  "Return string with pprint of v, and limit output to prevent blowup."
  [v]
  (with-out-str (binding [*print-length* 32 *print-level* 6] (pprint v


Everything seems to work as expected, except when trying to print a var value 
of nil:


user=> (pprint #'clojure.core/*print-length*)
#
nil
user=> (clj-ns-browser.utils/pprint-str #'clojure.core/*print-length*)
"#\n"
user=> (with-out-str (binding [*print-length* 32 *print-level* 6] (pprint 
#'clojure.core/*print-length*)))
"#\n"
user=> (binding [*print-length* 32 *print-level* 6] (pprint 
#'clojure.core/*print-length*))#
nil
user=> (binding [*print-length* 33 *print-level* 6] (pprint 
#'clojure.core/*print-length*))
#
nil
user=> 


It seems that the *print-length* binding-value is printed out when the 
var-value is nil.

Bug?
Feature?
Should I have used binding in a different way?

Thanks, FrankS.



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Tutorial/examples of pprint dispatch functions

[Kevin Downey]

https://gist.github.com/1314616

On Tue, Oct 25, 2011 at 6:33 AM, Alasdair MacLeod
 wrote:
> Hello,
>
> Are there any tutorials or examples of setting up pprint dispatch
> functions?  I know the docs suggest looking at the source, but I find
> it a bit cryptic.  In particular I would like to see if it's possible
> to dispatch on meta-data, record types or more arbitrary values in a
> map etc.
>
> thanks, Alasdair
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Tutorial/examples of pprint dispatch functions

[Alasdair MacLeod]

Hello,

Are there any tutorials or examples of setting up pprint dispatch
functions?  I know the docs suggest looking at the source, but I find
it a bit cryptic.  In particular I would like to see if it's possible
to dispatch on meta-data, record types or more arbitrary values in a
map etc.

thanks, Alasdair

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Increasing indent level in pprint

[Tom Faulhaber]

Hmmm, looking back at the code, I see that I mis-remembered the fact
that lists and vectors were different. They both (along with maps)
will break rather than fill. Arrays and sets both fill rather than
break.

I'm not sure how much logic there is around this. It just fit my
intuition about how the different structures would be most likely used
when I wrote it. It still seems about right. But if folks think it
should be different, it's easy to change.

On Jul 19, 1:19 pm, Sean Corfield  wrote:
> On Tue, Jul 19, 2011 at 12:03 AM, Tom Faulhaber  
> wrote:
> > Sean's remark is right for writing code, but not really relevant for
> > pretty printed data structures. The pretty printer will either avoid
> > "(foo a" followed by a line break or fill that line full. (By default,
> > for lists it breaks the lines and for vectors it fills them.)
>
> Interesting. I didn't realize it took a different approach.
>
> Out of curiosity, what is the thinking behind the difference between
> lists and vectors?
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
> Railo Technologies, Inc. --http://www.getrailo.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Increasing indent level in pprint

[Sean Corfield]

On Tue, Jul 19, 2011 at 12:03 AM, Tom Faulhaber  wrote:
> Sean's remark is right for writing code, but not really relevant for
> pretty printed data structures. The pretty printer will either avoid
> "(foo a" followed by a line break or fill that line full. (By default,
> for lists it breaks the lines and for vectors it fills them.)

Interesting. I didn't realize it took a different approach.

Out of curiosity, what is the thinking behind the difference between
lists and vectors?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Increasing indent level in pprint

[Tom Faulhaber]

Sean's remark is right for writing code, but not really relevant for
pretty printed data structures. The pretty printer will either avoid
"(foo a" followed by a line break or fill that line full. (By default,
for lists it breaks the lines and for vectors it fills them.)

While there's no way to just set the indent, you can get this effect
with a little work.

The pretty printer allows customization of the output format using
dispatch functions.

By default it uses simple-dispatch, defined here:
https://github.com/clojure/clojure/blob/d1e39b1ec7fc65907b13458d7ec70b0839f3f85e/src/clj/clojure/pprint/dispatch.clj#L65

I have created a variant of simple dispatch that does the two
character indent (as per your example above). I through a little
project on github: https://github.com/tomfaulhaber/pprint-indent. The
README is basically a copy of your second example run in my repl. The
source is in 
https://github.com/tomfaulhaber/pprint-indent/blob/master/src/indent/indent.clj
for the curious.

Feel free to modify to taste. :)





On Jul 16, 10:52 pm, Asim Jalis  wrote:
> Okay. I see what you mean.
>
> On Jul 16, 2011, at 8:39 PM, Sean Corfield  wrote:
>
>
>
>
>
>
>
> > On Sat, Jul 16, 2011 at 7:05 PM, Asim Jalis  wrote:
> >> The position of the braces might be a red herring here. I was mostly
> >> interested in figuring out how to increase the indentation level from
> >> 1 to something larger. Even an indentation step of 2 for each level
> >> would be easier on the eye than 1.
>
> > My point was that the "natural" Lisp/Clojure indentation is to match
> > the items above so for:
>
> > {:something
>
> > the natural indentation is 1 and for:
>
> > (foo a
>
> > the natural indentation is 5: '(', 'f', 'o', 'o', ' '.
>
> > Indentation is not some fixed quantity you can change - it's dependent
> > on the structure of the data/code and the length of the symbols.
> > --
> > Sean A Corfield -- (904) 302-SEAN
> > An Architect's View --http://corfield.org/
> > World Singles, LLC. --http://worldsingles.com/
> > Railo Technologies, Inc. --http://www.getrailo.com/
>
> > "Perfection is the enemy of the good."
> > -- Gustave Flaubert, French realist novelist (1821-1880)
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Increasing indent level in pprint

[Asim Jalis]

Okay. I see what you mean. 

On Jul 16, 2011, at 8:39 PM, Sean Corfield  wrote:

> On Sat, Jul 16, 2011 at 7:05 PM, Asim Jalis  wrote:
>> The position of the braces might be a red herring here. I was mostly
>> interested in figuring out how to increase the indentation level from
>> 1 to something larger. Even an indentation step of 2 for each level
>> would be easier on the eye than 1.
> 
> My point was that the "natural" Lisp/Clojure indentation is to match
> the items above so for:
> 
> {:something
> 
> the natural indentation is 1 and for:
> 
> (foo a
> 
> the natural indentation is 5: '(', 'f', 'o', 'o', ' '.
> 
> Indentation is not some fixed quantity you can change - it's dependent
> on the structure of the data/code and the length of the symbols.
> -- 
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
> Railo Technologies, Inc. -- http://www.getrailo.com/
> 
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Increasing indent level in pprint

[Sean Corfield]

On Sat, Jul 16, 2011 at 7:05 PM, Asim Jalis  wrote:
> The position of the braces might be a red herring here. I was mostly
> interested in figuring out how to increase the indentation level from
> 1 to something larger. Even an indentation step of 2 for each level
> would be easier on the eye than 1.

My point was that the "natural" Lisp/Clojure indentation is to match
the items above so for:

{:something

the natural indentation is 1 and for:

(foo a

the natural indentation is 5: '(', 'f', 'o', 'o', ' '.

Indentation is not some fixed quantity you can change - it's dependent
on the structure of the data/code and the length of the symbols.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Increasing indent level in pprint

[Asim Jalis]

The position of the braces might be a red herring here. I was mostly
interested in figuring out how to increase the indentation level from
1 to something larger. Even an indentation step of 2 for each level
would be easier on the eye than 1.

On Sat, Jul 16, 2011 at 4:23 PM, Sean Corfield  wrote:
> On Sat, Jul 16, 2011 at 12:46 PM, Asim Jalis  wrote:
>> Is there an easy way to increase the indent of pprint data structures
>> from 1 to something like 2 or 4? I've been searching on Google and
>> going through the docs and don't see anything.
>>
>> For example, I would like the following command to produce something
>> closer to "output 2" than to "output 1".
>
> Just curious, is your background Java or some similar C-style language?
>
> I ask because folks coming from that sort of background tend to want
> braces and parentheses on separate lines and fixed indentation whereas
> the Lisp crowd tend to want trailing braces and "natural" indentation,
> i.e., continuation lines are indented so elements line up:
>
> (somefn arg1
>        (f arg2))
>
> If I got that right the (f... should line up with arg1 above it.
>
> It took me a while to get used to the "Clojure way" of code/data
> layout but now I tend to avoid commas and just go with the flow of how
> pprint or my IDE wants to format stuff and I like the concise
> consistency.
>
> Sorry that doesn't answer your question but I hope it helps explain
> why the default pprint output looks the way it does?
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
> Railo Technologies, Inc. -- http://www.getrailo.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Increasing indent level in pprint

[Sean Corfield]

On Sat, Jul 16, 2011 at 12:46 PM, Asim Jalis  wrote:
> Is there an easy way to increase the indent of pprint data structures
> from 1 to something like 2 or 4? I've been searching on Google and
> going through the docs and don't see anything.
>
> For example, I would like the following command to produce something
> closer to "output 2" than to "output 1".

Just curious, is your background Java or some similar C-style language?

I ask because folks coming from that sort of background tend to want
braces and parentheses on separate lines and fixed indentation whereas
the Lisp crowd tend to want trailing braces and "natural" indentation,
i.e., continuation lines are indented so elements line up:

(somefn arg1
(f arg2))

If I got that right the (f... should line up with arg1 above it.

It took me a while to get used to the "Clojure way" of code/data
layout but now I tend to avoid commas and just go with the flow of how
pprint or my IDE wants to format stuff and I like the concise
consistency.

Sorry that doesn't answer your question but I hope it helps explain
why the default pprint output looks the way it does?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Increasing indent level in pprint

[Asim Jalis]

Is there an easy way to increase the indent of pprint data structures
from 1 to something like 2 or 4? I've been searching on Google and
going through the docs and don't see anything.

For example, I would like the following command to produce something
closer to "output 2" than to "output 1".

(pprint {:remote-addr "127.0.0.1", :scheme :http, :query-params {},
:session {}, :form-params {}, :request-method :get, :query-string nil,
:content-type nil, :cookies {"ring-session" {:value
"b3493c6e-40c3-441c-a75a-19d1a67e7b8d"}}, :uri "/", :server-name
"localhost", :params {}, :headers {"cache-control" "max-age=0",
"cookie" "ring-session=b3493c6e-40c3-441c-a75a-19d1a67e7b8d",
"accept-charset" "ISO-8859-1,utf-8;q=0.7,*;q=0.3", "accept-language"
"en-US,en;q=0.8", "accept-encoding" "gzip,deflate,sdch", "accept"
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"user-agent" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8)
AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122
Safari/534.30", "connection" "keep-alive", "host" "localhost:8080"},
:content-length nil, :server-port 8080, :character-encoding nil, :body
nil })

OUTPUT 1

{:remote-addr "127.0.0.1",
 :scheme :http,
 :query-params {},
 :session {},
 :form-params {},
 :request-method :get,
 :query-string nil,
 :content-type nil,
 :cookies
 {"ring-session" {:value "b3493c6e-40c3-441c-a75a-19d1a67e7b8d"}},
 :uri "/",
 :server-name "localhost",
 :params {},
 :headers
 {"user-agent" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8)
AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122
Safari/534.30",
  "cookie" "ring-session=b3493c6e-40c3-441c-a75a-19d1a67e7b8d",
  "accept-charset" "ISO-8859-1,utf-8;q=0.7,*;q=0.3",
  "accept" "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
  "host" "localhost:8080",
  "cache-control" "max-age=0",
  "accept-encoding" "gzip,deflate,sdch",
  "accept-language" "en-US,en;q=0.8",
  "connection" "keep-alive"},
 :content-length nil,
 :server-port 8080,
 :character-encoding nil,
 :body nil}

OUTPUT 2

{
:remote-addr "127.0.0.1",
:scheme :http,
:query-params {},
:session {},
:form-params {},
:request-method :get,
:query-string nil,
:content-type nil,
:cookies
{
"ring-session" {:value "b3493c6e-40c3-441c-a75a-19d1a67e7b8d"}
},
:uri "/",
:server-name "localhost",
:params {},
:headers
{
"user-agent" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8)
AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122
Safari/534.30",
"cookie" "ring-session=b3493c6e-40c3-441c-a75a-19d1a67e7b8d",
"accept-charset" "ISO-8859-1,utf-8;q=0.7,*;q=0.3",
"accept"
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"host" "localhost:8080",
"cache-control" "max-age=0",
"accept-encoding" "gzip,deflate,sdch",
"accept-language" "en-US,en;q=0.8",
"connection" "keep-alive"
},
:content-length nil,
:server-port 8080,
:character-encoding nil,
:body nil
}

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: clojure.pprint/pprint and map-like structures

[Shantanu Kumar]

Thanks! It's pretty useful.

Regards,
Shantanu

On Jan 26, 9:27 pm, Ken Wesson  wrote:
> On Wed, Jan 26, 2011 at 10:58 AM, Shantanu Kumar
>
>  wrote:
> > Hi,
>
> > I have created some 'deftype' objects and 'extend'ed
> > clojure.lang.ILookup to them to make them behave like maps. How can I
> > get the clojure.pprint/pprint to pretty-print them like maps?
>
> A deftype can override toString like this:
>
> user=> (deftype Foo [n]
>   java.lang.Object
>     (toString [this] (str "Foo<" n ">")))
> user.Foo
> user=> (Foo. 3)
> #>
> user=>
>
> It still gets printed the way generic objects normally do, though:
> #.
>
> Fortunately, pprint lets you override this behavior by adding methods
> to a multimethod called *simple-dispatch*:
>
> user=> (defmethod clojure.contrib.pprint/*simple-dispatch* Foo [x]
> (print (.toString x)))
> #
> user=> (Foo. 3)
> Foo<3>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: clojure.pprint/pprint and map-like structures

[Ken Wesson]

On Wed, Jan 26, 2011 at 10:58 AM, Shantanu Kumar
 wrote:
> Hi,
>
> I have created some 'deftype' objects and 'extend'ed
> clojure.lang.ILookup to them to make them behave like maps. How can I
> get the clojure.pprint/pprint to pretty-print them like maps?

A deftype can override toString like this:

user=> (deftype Foo [n]
  java.lang.Object
(toString [this] (str "Foo<" n ">")))
user.Foo
user=> (Foo. 3)
#>
user=>

It still gets printed the way generic objects normally do, though:
#.

Fortunately, pprint lets you override this behavior by adding methods
to a multimethod called *simple-dispatch*:

user=> (defmethod clojure.contrib.pprint/*simple-dispatch* Foo [x]
(print (.toString x)))
#
user=> (Foo. 3)
Foo<3>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

clojure.pprint/pprint and map-like structures

[Shantanu Kumar]

Hi,

I have created some 'deftype' objects and 'extend'ed
clojure.lang.ILookup to them to make them behave like maps. How can I
get the clojure.pprint/pprint to pretty-print them like maps?

Regards,
Shantanu

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: pprint

[Tom Faulhaber]

Hey Laurent,

Making this more comprehensible is part of my plan for documenting how
to create dispatch. You don't really need to understand the whole XP
paper to know enough to understand how pretty print works. Let me lay
out a quick overview here:

High-level concepts

Top-level concept: the pretty printer tries to keep things together on
a line unless they don't fit, in which case it splits the lines in
appropriate places and indents successive lines to the right place.

2nd top-level concept: pretty printing is a mechanism, not a fixed
function. The actual printing is controlled by dispatch functions that
in turn call functions in the underlying mechanism. There are four
examples you can look at to see how this works in Clojure: two
functions in clojure/contrib/pprint/dispatch.clj that implement the
standard "simple" dispatch and the specialized "code" dispatch. The
other two are in clojure/contrib/pprint/examples and format clojure
structure as pretty printed json or xml.

There are two ways to define the dispatch function (which is basically
always a multimethod because you do different things for different
types): writing it out as a function or specifying a format for cl-
format using the formatter-out function. I'll assume the first method
here, since it will be more familiar.

Logical blocks

The "things" that the pretty printer thinks about are "logical
blocks." These usually correspond to things like lists, vectors, maps
and such. Logical blocks are nested (just like lists, vectors,...).

Logical blocks are created by the macro pprint-logical-block. This
macro wraps its body in a logical block and allows you to specify
prefix and suffix (e.g., "(" and ")").

Control variables

There are two key variables that control where the pretty printer
decides to break lines, *print-right-margin* and *print-miser-width*.
The first is the most significant and tells pprint where you want it
to try get the line to break. *print-miser-width* is a width back to
the left from the right margin where you want pprint to be really
aggressive about breaking lines (this is useful for heavily nested
structures).

For example, "let" may not break between the let and the binding
vector, but if the let construct is to the right of the miser width
boundary (i.e. very indented), it might put a newline there. This
makes it more likely that we'll be able to fit even more deeply nested
structures inside the right margin.

Note that the pretty printer doesn't completely guarantee that it will
be able to print a structure within the right margin, but it does a
pretty good job in practice.

Newlines

The are 4 kinds of newlines that the dispatch function can specify:
linear, fill, miser, and mandatory. These are created by the pprint-
newline function which takes a keyword argument specifying the type.
Simplifying a little, we can consider each type:

Linear: If a logical block doesn't fit on a single line, *all* the
linear newlines in it are emitted as real newlines, otherwise none of
them are. (For example, simple-dispatch specifies a linear newline
between each element of a list. So either the list is printed on a
single line, or every element is printed on its own line).

Fill: If a logical block doesn't fit on a single line, only those fill
newlines that are necessary to make the parts fit are emitted and the
rest are ignored. (For example, when formatting XML attributes, we fit
as many as possible on a single line before inserting a newline.)

Miser: If you see a miser newline when you are to the right of the
miser width boundary, miser newlines are emitted, otherwise they are
ignored.

Mandatory: A mandatory newline is always emitted.

Indenting

By default, when a newline is emitted the next line is indented to the
column where the first character of the current logical block was
emitted (after any prefix). So simple list structures line up right
after the opening paren, for instance.

You can override this default with pprint-indent which allows you to
specify an indent relative to the beginning of the block or the
current column position.

Write and write-out

"write" is a general function which will (in general) allow you to
emit an object using the pretty printer. In dispatch functions, we use
"write-out" which is a version of write that assumes that *out* has
been correctly set up for the pretty printer. You can think of write-
out as a recursive call to the pretty printer when you see it or use
it in dispatch functions.

I think that should give you enough to get started with. Check out the
dispatch functions I mentioned above to see all of this in action. And
let me know if I clarify any more stuff.

Tom


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this gro

Re: pprint

[Laurent PETIT]

Hi Tom,

2009/7/2 Tom Faulhaber :
>
>
>
>> Are you suggesting that "clojure reader parsed code" could be first
>> translated back to String and reinjected to the "source code reader" ?
>> Indeed that could simplify final implementation. I don't know what the
>> impact on performance would be, though.
>
> No, that wouldn't work because the clojure reader is lossy.
>
> What I have in mind is simply not having a clojure reader version, but
> only your own "enhanced" version.
>
> One thing that I was thinking is that this might be identical to the
> Clojure-produced version but with extra metadata attached to the
> structure to indicate "source extras" (like comments and metadata
> annotations) and syntax variations (unclosed parens and the like).
> This would be nice for you if you're using the reader produced data
> for other stuff.
>
> On the other hand, it might be more useful to wrap the structure the
> you read in a container (or set of containers) that annotates it. A
> simple transform could then "extract" reader compatible version if you
> needed it.
>
>
>> > One experiment I've been doing is to build an "Object Explorer" based
>> > on pprint. The thing I added (but that's not totally integrated back
>> > into pprint yet), is callbacks to let you map structure to output
>> > location. I use it there for allowing the user to click on parts of
>> > the object displayed to expand and contract its subobjects.
>>
>> I must look at the code, but is this some sort of implementation of
>> the Builder design pattern ?
>
> Not really.
>
> What you have is a Clojure object that you want to explore, but it's
> huge, so you don't just want to print it and look at it.
>
> Instead you use the control variables *print-length* and *print-level*
> to only print a high-level view of it (into a text control in a swing
> app).
>
> Then when you want to go deeper into some part of the structure, you
> just click on it and it expands (i.e., *print-level* is incremented,
> but only for that part of the structure). Clicking again contracts it.
>
> This is accomplished via callbacks in the pretty printer that allow us
> to track where on the screen each part of the logical structure is.
> (Simplistically, remember where I enter a particular level of list and
> where I exit it.)
>
>> Wow, you gave me a lot of homework ;-)
>
> Just trying to keep you busy :-)

I don't know if it's me, but while doing my homework reading the X
stuff pdf, I almost fell asleep ... :-$ (ok, it's generally late by
night when I can start work on the eclipse plugin, this can also
explain things :-)

But seriously, it seems that the reading assumes from me a basic
knowledge I don't have ... it goes very quickly into detail I don't
understand, while leaving me alone to try understanding a little
textual graphic abstractly representing the notions of logical blocks,
etc.

Do you know of something more understandable (for a dopey like me  !
:-) that I could read first ?

>
>> Well, honestly, 300 to 400 lines per second does not seem very
>> performant.
>
> Agreed. Which is why I mentioned the incremental thing.
>
>> This implies that the reformating of clojure.core would
>> take 10 seconds  I indeed expected something around "very fast"
>> for a medium size file (300 - 400 lines), and 1 to 2 seconds for
>> something big as clojure.core (but maybe I'm just dreaming). Do you
>> already know where to look for better perf ?
>
> Those speeds may be achievable, but even 1-2 seconds will seem slow if
> you're doing it all the time. I believe that most systems that do this
> use incremental algorithms so as to be O(1) and not O(n) on the file
> size.
>
> I do have some places to look for more performance, but I have no idea
> how much faster I can make it go before I have to make hard choices.
> It seems like every few weeks I take a whack at performance and know
> it up an order of magnitude, but who knows how many of those rabbits
> (if any) are left in the hat :-).
>
> If you really think about all the cases, pretty printing is reasonably
> complex. Add to that my desire to have a pretty printer with flexible
> dispatch (which is what would make it work at all for apps like this)
> and there's more overhead still. But you can assume that I'll get you
> a bunch more performance over time.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: pprint

[Tom Faulhaber]

> Are you suggesting that "clojure reader parsed code" could be first
> translated back to String and reinjected to the "source code reader" ?
> Indeed that could simplify final implementation. I don't know what the
> impact on performance would be, though.

No, that wouldn't work because the clojure reader is lossy.

What I have in mind is simply not having a clojure reader version, but
only your own "enhanced" version.

One thing that I was thinking is that this might be identical to the
Clojure-produced version but with extra metadata attached to the
structure to indicate "source extras" (like comments and metadata
annotations) and syntax variations (unclosed parens and the like).
This would be nice for you if you're using the reader produced data
for other stuff.

On the other hand, it might be more useful to wrap the structure the
you read in a container (or set of containers) that annotates it. A
simple transform could then "extract" reader compatible version if you
needed it.


> > One experiment I've been doing is to build an "Object Explorer" based
> > on pprint. The thing I added (but that's not totally integrated back
> > into pprint yet), is callbacks to let you map structure to output
> > location. I use it there for allowing the user to click on parts of
> > the object displayed to expand and contract its subobjects.
>
> I must look at the code, but is this some sort of implementation of
> the Builder design pattern ?

Not really.

What you have is a Clojure object that you want to explore, but it's
huge, so you don't just want to print it and look at it.

Instead you use the control variables *print-length* and *print-level*
to only print a high-level view of it (into a text control in a swing
app).

Then when you want to go deeper into some part of the structure, you
just click on it and it expands (i.e., *print-level* is incremented,
but only for that part of the structure). Clicking again contracts it.

This is accomplished via callbacks in the pretty printer that allow us
to track where on the screen each part of the logical structure is.
(Simplistically, remember where I enter a particular level of list and
where I exit it.)

> Wow, you gave me a lot of homework ;-)

Just trying to keep you busy :-)

> Well, honestly, 300 to 400 lines per second does not seem very
> performant.

Agreed. Which is why I mentioned the incremental thing.

> This implies that the reformating of clojure.core would
> take 10 seconds  I indeed expected something around "very fast"
> for a medium size file (300 - 400 lines), and 1 to 2 seconds for
> something big as clojure.core (but maybe I'm just dreaming). Do you
> already know where to look for better perf ?

Those speeds may be achievable, but even 1-2 seconds will seem slow if
you're doing it all the time. I believe that most systems that do this
use incremental algorithms so as to be O(1) and not O(n) on the file
size.

I do have some places to look for more performance, but I have no idea
how much faster I can make it go before I have to make hard choices.
It seems like every few weeks I take a whack at performance and know
it up an order of magnitude, but who knows how many of those rabbits
(if any) are left in the hat :-).

If you really think about all the cases, pretty printing is reasonably
complex. Add to that my desire to have a pretty printer with flexible
dispatch (which is what would make it work at all for apps like this)
and there's more overhead still. But you can assume that I'll get you
a bunch more performance over time.

Tom
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: pprint

[Laurent PETIT]

Hi Philip,

2009/7/1 philip.hazel...@gmail.com :
>
> On Jul 1, 9:52 am, Laurent PETIT  wrote:
>> As far as IDE integration is concerned, i would not bother (at first)
>> about incremental thing. I rather intend to always parse the entire
>> edited file content (of course if this causes a performance problem, I
>> might rethink about it). For performance testing, I've found that
>> clojure/core.clj is a good candidate :-)
>
> You may have considered this already, but always reparsing the whole
> file will make things interesting when the code is in an invalid state
> during editing. Top-level forms will look like they're several levels
> deep, potentially in places they really shouldn't be.

Not sure whether it is ironic or not when you write "will make things
interesting" ? :-)
The already existing syntax coloring of clojuredev (with rainbow
parens enabled) does just that, reparsing the whole file everytime.
And I've found it useful to see that what I really know is a top level
form does not have the right color. It helps identify where the
problem begins ...
>
> Depending on what you do with the information, that might not be a
> problem. And there's certainly something to be said for starting with
> the simplest possible implementation. But for a more powerful
> approach, it's possible to use information from the user's typing to
> work out "this ( is probably unmatched, and the next ) is closing the
> preceeding (".
>
> Source: 
> http://www.codekana.com/blog/2009/04/02/on-the-speed-of-light-innovation-and-the-future-of-parsing/
> (You can probably scroll down to "on a whim".)

More homework ! :-) Thanks for the pointer,

Regards,

-- 
Laurent

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: pprint

[Laurent PETIT]

Hi Tom,

2009/7/1 Tom Faulhaber :
>
> Laurent,
>
> Sounds like a good plan.
>
> To answer your questions:
>
>> I'll play with your code. Do you have a first pass over the clojure
>> reader to attach other meta information as you go, or do you directly
>> consume the clojure data structures the reader passes to you ?
>
> pprint operates on clojure objects directly and doesn't really
> consider where they came from. It has no concept of parsing input at
> all.  However, output is very flexible, being driven by user-definable
> dispatch functions. The architecture is based on the standard Lisp
> pretty print architecture called XP. (This is the pretty printer
> that's included in Common Lisp, for instance). You might want to look
> at the paper "XP. A Common Lisp Pretty Printing System" which is
> available at http://dspace.mit.edu/handle/1721.1/6504. The Clojure
> implementation is more "clojure-y" but the algorithms and concepts are
> substantially the same.

I'll definitely look at it, thanks for the pointer !

> The pretty printer includes two dispatch functions, simple and code.
> These are defined in clojure.contrib.pprint.dispatch.clj. You probably
> want to skim over those to see the structure of the Clojure
> implementation of this stuff.

> I've begun to do more complete documentation of the pretty printer and
> how to do dispatch here: 
> http://code.google.com/p/clojure-contrib/wiki/PrettyPrinting
> but I've gotten distracted with getting all the doc moved from google
> code to github. I should be back to fleshing out that documentation
> soon.
>

Good to know, thanks!

>
>> If so,
>> then certainly there would be the need to have an intermediate
>> structure that would be the output of both "clojure reader parsed
>> code" and "source code preserving reader parsed code" ? So that the
>> rest of the formatting code is decoupled from that ? (But that will
>> certainly be lots of changes, and in all parts I guess).
>
> Not clear to me that you would need the "clojure reader parsed code"
> in your implementation since you wouldn't be using that directly and
> you could extract relevant information from the source code preserving
> reader (like func names, etc.), but obviously you know more about how
> you're using the results.

Are you suggesting that "clojure reader parsed code" could be first
translated back to String and reinjected to the "source code reader" ?
Indeed that could simplify final implementation. I don't know what the
impact on performance would be, though.

>
> But yes, you will want to work in terms of an intermediate form that
> you can pprint and work on as well.
>
> Then you would have a modified version of the code-dispatch that
> understood the enhanced data structures that were in that version (I
> don't think that should be too hard).
>
> One experiment I've been doing is to build an "Object Explorer" based
> on pprint. The thing I added (but that's not totally integrated back
> into pprint yet), is callbacks to let you map structure to output
> location. I use it there for allowing the user to click on parts of
> the object displayed to expand and contract its subobjects.

I must look at the code, but is this some sort of implementation of
the Builder design pattern ?

> I can imagine that in a IDE this could be used to support structural
> motion, paredit type things, etc.
>
> I did a little talk on this here: http://blip.tv/file/2286313 and the
> current state of the explorer is on github: 
> http://github.com/tomfaulhaber/clj-explorer

Wow, you gave me a lot of homework ;-)

>>
>> As far as IDE integration is concerned, i would not bother (at first)
>> about incremental thing. I rather intend to always parse the entire
>> edited file content (of course if this causes a performance problem, I
>> might rethink about it). For performance testing, I've found that
>> clojure/core.clj is a good candidate :-)
>>
>
> Yeah, I use core.clj a lot too. I *do* worry about performance here.
> pprint currently renders 300-400 lines per second on my machine. It's
> getting faster, but I doubt it will ever exceed 10x where it is now
> (though I might surprise myself).

Well, honestly, 300 to 400 lines per second does not seem very
performant. This implies that the reformating of clojure.core would
take 10 seconds  I indeed expected something around "very fast"
for a medium size file (300 - 400 lines), and 1 to 2 seconds for
something big as clojure.core (but maybe I'm just dreaming). Do you
already know where to look for better perf ?

>
> Keep

Re: pprint

[philip.hazel...@gmail.com]

On Jul 1, 9:52 am, Laurent PETIT  wrote:
> As far as IDE integration is concerned, i would not bother (at first)
> about incremental thing. I rather intend to always parse the entire
> edited file content (of course if this causes a performance problem, I
> might rethink about it). For performance testing, I've found that
> clojure/core.clj is a good candidate :-)

You may have considered this already, but always reparsing the whole
file will make things interesting when the code is in an invalid state
during editing. Top-level forms will look like they're several levels
deep, potentially in places they really shouldn't be.

Depending on what you do with the information, that might not be a
problem. And there's certainly something to be said for starting with
the simplest possible implementation. But for a more powerful
approach, it's possible to use information from the user's typing to
work out "this ( is probably unmatched, and the next ) is closing the
preceeding (".

Source: 
http://www.codekana.com/blog/2009/04/02/on-the-speed-of-light-innovation-and-the-future-of-parsing/
(You can probably scroll down to "on a whim".)

-Phil
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: pprint

[Tom Faulhaber]

Laurent,

Sounds like a good plan.

To answer your questions:

> I'll play with your code. Do you have a first pass over the clojure
> reader to attach other meta information as you go, or do you directly
> consume the clojure data structures the reader passes to you ?

pprint operates on clojure objects directly and doesn't really
consider where they came from. It has no concept of parsing input at
all.  However, output is very flexible, being driven by user-definable
dispatch functions. The architecture is based on the standard Lisp
pretty print architecture called XP. (This is the pretty printer
that's included in Common Lisp, for instance). You might want to look
at the paper "XP. A Common Lisp Pretty Printing System" which is
available at http://dspace.mit.edu/handle/1721.1/6504. The Clojure
implementation is more "clojure-y" but the algorithms and concepts are
substantially the same.

The pretty printer includes two dispatch functions, simple and code.
These are defined in clojure.contrib.pprint.dispatch.clj. You probably
want to skim over those to see the structure of the Clojure
implementation of this stuff.

I've begun to do more complete documentation of the pretty printer and
how to do dispatch here: 
http://code.google.com/p/clojure-contrib/wiki/PrettyPrinting
but I've gotten distracted with getting all the doc moved from google
code to github. I should be back to fleshing out that documentation
soon.


> If so,
> then certainly there would be the need to have an intermediate
> structure that would be the output of both "clojure reader parsed
> code" and "source code preserving reader parsed code" ? So that the
> rest of the formatting code is decoupled from that ? (But that will
> certainly be lots of changes, and in all parts I guess).

Not clear to me that you would need the "clojure reader parsed code"
in your implementation since you wouldn't be using that directly and
you could extract relevant information from the source code preserving
reader (like func names, etc.), but obviously you know more about how
you're using the results.

But yes, you will want to work in terms of an intermediate form that
you can pprint and work on as well.

Then you would have a modified version of the code-dispatch that
understood the enhanced data structures that were in that version (I
don't think that should be too hard).

One experiment I've been doing is to build an "Object Explorer" based
on pprint. The thing I added (but that's not totally integrated back
into pprint yet), is callbacks to let you map structure to output
location. I use it there for allowing the user to click on parts of
the object displayed to expand and contract its subobjects.

I can imagine that in a IDE this could be used to support structural
motion, paredit type things, etc.

I did a little talk on this here: http://blip.tv/file/2286313 and the
current state of the explorer is on github: 
http://github.com/tomfaulhaber/clj-explorer

>
> As far as IDE integration is concerned, i would not bother (at first)
> about incremental thing. I rather intend to always parse the entire
> edited file content (of course if this causes a performance problem, I
> might rethink about it). For performance testing, I've found that
> clojure/core.clj is a good candidate :-)
>

Yeah, I use core.clj a lot too. I *do* worry about performance here.
pprint currently renders 300-400 lines per second on my machine. It's
getting faster, but I doubt it will ever exceed 10x where it is now
(though I might surprise myself).

Keep me up to date on how it's going and feel free to bother me about
whatever. (You can often find me in #clojure as replaca, also.)

Tom
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: pprint

[Laurent PETIT]

Hi Tom,

Thanks for the answer. I already have some embryonic antlr grammar for
clojure, but I'm willing to give pprint a thourough try.

I'll play with your code. Do you have a first pass over the clojure
reader to attach other meta information as you go, or do you directly
consume the clojure data structures the reader passes to you ? If so,
then certainly there would be the need to have an intermediate
structure that would be the output of both "clojure reader parsed
code" and "source code preserving reader parsed code" ? So that the
rest of the formatting code is decoupled from that ? (But that will
certainly be lots of changes, and in all parts I guess).

As far as IDE integration is concerned, i would not bother (at first)
about incremental thing. I rather intend to always parse the entire
edited file content (of course if this causes a performance problem, I
might rethink about it). For performance testing, I've found that
clojure/core.clj is a good candidate :-)

Regards,

-- 
Laurent

2009/6/30 Tom Faulhaber :
>
> Hi Laurent,
>
> I think that pprint might be a good foundation for what you are doing,
> but there are a couple of issues that need to be dealt with first.
>
> First, pprint works directly on Clojure objects and not strings, so
> the code will need to be read first.
>
> Second, the Clojure reader is lossy - it strips comments, metadata
> tags (#^{}) and expands forms like backquote and reader time
> evaluation before passing you the result.
>
> The first thing I would do is look at making a modified reader that
> could read chunks of s-expression and pass back raw data. In a perfect
> world, this reader would be much more resistant to syntax problems
> (for example by "assuming" extra opening or closing brackets of
> various types).
>
> Then I would look at how I was going to attach the pprint to the
> editor. In practice, I think you want the reformatting to be very
> incremental, working on small chunks of code at a time, but you know
> better than I.
>
> Using the code dispatch in pretty printing should be pretty easy once
> you have this infrastructure. You'll probably want to customize it a
> little, but that's fairly straightforward. You'll also probably want
> to "clean up" any syntax corrections you made. I might think about
> adding metadata to the read structure and then using that in the
> dispatch to skip writing open parens that weren't really there, for
> instance.
>
> I've been thinking about doing all this, but it's not at the top of my
> list right now (working on a new contrib autodoc tool and making
> pprint cleaner and faster plus my real job!). But I'm happy to discuss/
> help in the short term.
>
> HTH,
>
> Tom
>
> On Jun 30, 7:08 am, Laurent PETIT  wrote:
>> Hi all,
>>
>> I want to add source code formatting / auto-indenting to the clojure
>> plugin for eclipse.
>>
>> I had asked other IDE plugin creators, and it seems that they
>> leveraged the specifics of their respective platforms to do so. So I
>> have nothing substantial to "steal from them" not requiring a fair
>> amount of rework :-)
>>
>> I'm now facing the following two paths :
>>
>>  * try to leverage Eclipse's way of doing clojure source code
>> formatting / auto-indenting and create yet another lib for doing that
>> very specifically
>>
>>  * try to do it in clojure so that it can also be used as a standalone
>> command-line / whatever utility for mass source code reformatting ...
>>
>> So what is my question ? :-)
>>
>> Do you know if pprint lib now is (or will in a near future) be able to
>> handle this use case : that is not only formatting clojure code
>> returned by the reader, but also clojure code as string, and
>> potentially broken code (and so it would have to preserve comments,
>> literal metadata in the exact form they were written, etc.)
>>
>> Do you know whether there is another existing effort to do this in
>> plain clojure, or at least sufficiently independtly from an existing
>> IDE framework so that I can painlessly reuse it ?
>>
>> Thanks in advance,
>>
>> --
>> Laurent
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: pprint

[Tom Faulhaber]

Hi Laurent,

I think that pprint might be a good foundation for what you are doing,
but there are a couple of issues that need to be dealt with first.

First, pprint works directly on Clojure objects and not strings, so
the code will need to be read first.

Second, the Clojure reader is lossy - it strips comments, metadata
tags (#^{}) and expands forms like backquote and reader time
evaluation before passing you the result.

The first thing I would do is look at making a modified reader that
could read chunks of s-expression and pass back raw data. In a perfect
world, this reader would be much more resistant to syntax problems
(for example by "assuming" extra opening or closing brackets of
various types).

Then I would look at how I was going to attach the pprint to the
editor. In practice, I think you want the reformatting to be very
incremental, working on small chunks of code at a time, but you know
better than I.

Using the code dispatch in pretty printing should be pretty easy once
you have this infrastructure. You'll probably want to customize it a
little, but that's fairly straightforward. You'll also probably want
to "clean up" any syntax corrections you made. I might think about
adding metadata to the read structure and then using that in the
dispatch to skip writing open parens that weren't really there, for
instance.

I've been thinking about doing all this, but it's not at the top of my
list right now (working on a new contrib autodoc tool and making
pprint cleaner and faster plus my real job!). But I'm happy to discuss/
help in the short term.

HTH,

Tom

On Jun 30, 7:08 am, Laurent PETIT  wrote:
> Hi all,
>
> I want to add source code formatting / auto-indenting to the clojure
> plugin for eclipse.
>
> I had asked other IDE plugin creators, and it seems that they
> leveraged the specifics of their respective platforms to do so. So I
> have nothing substantial to "steal from them" not requiring a fair
> amount of rework :-)
>
> I'm now facing the following two paths :
>
>  * try to leverage Eclipse's way of doing clojure source code
> formatting / auto-indenting and create yet another lib for doing that
> very specifically
>
>  * try to do it in clojure so that it can also be used as a standalone
> command-line / whatever utility for mass source code reformatting ...
>
> So what is my question ? :-)
>
> Do you know if pprint lib now is (or will in a near future) be able to
> handle this use case : that is not only formatting clojure code
> returned by the reader, but also clojure code as string, and
> potentially broken code (and so it would have to preserve comments,
> literal metadata in the exact form they were written, etc.)
>
> Do you know whether there is another existing effort to do this in
> plain clojure, or at least sufficiently independtly from an existing
> IDE framework so that I can painlessly reuse it ?
>
> Thanks in advance,
>
> --
> Laurent
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

pprint

[Laurent PETIT]

Hi all,

I want to add source code formatting / auto-indenting to the clojure
plugin for eclipse.

I had asked other IDE plugin creators, and it seems that they
leveraged the specifics of their respective platforms to do so. So I
have nothing substantial to "steal from them" not requiring a fair
amount of rework :-)

I'm now facing the following two paths :

 * try to leverage Eclipse's way of doing clojure source code
formatting / auto-indenting and create yet another lib for doing that
very specifically

 * try to do it in clojure so that it can also be used as a standalone
command-line / whatever utility for mass source code reformatting ...

So what is my question ? :-)

Do you know if pprint lib now is (or will in a near future) be able to
handle this use case : that is not only formatting clojure code
returned by the reader, but also clojure code as string, and
potentially broken code (and so it would have to preserve comments,
literal metadata in the exact form they were written, etc.)

Do you know whether there is another existing effort to do this in
plain clojure, or at least sufficiently independtly from an existing
IDE framework so that I can painlessly reuse it ?


Thanks in advance,

-- 
Laurent

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---