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<http://www.google.com/url?q=http%3A%2F%2Fdev.clojure.org%2Fjira%2Fbrowse%2FCLJ-1278&sa=D&sntz=1&usg=AFQjCNF56KKjllTJ7mHNbmI4cu-U8QGK-g>) >> >> 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 <https://github.com/google/hesokuri> 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: >>> #<core$partial$fn__4228 clojure.core$partial$fn__4228@1ee1dea2> >>> >>> 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<https://github.com/google/hesokuri/blob/b60cb7222cfdd672e394ef6f22b80c94278fe3a0/src/hesokuri/see.clj#L35>) >>> >>> 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.
