Although (as I just realized), it fails miserably with closures. On Thu, May 5, 2011 at 11:38 PM, Jonathan Fischer Friberg < odysso...@gmail.com> wrote:
> I created a new datatype to solve this problem: > http://gist.github.com/958001 > c-fn creates a comparable function; > > (let [fnmaker4 (fn [coll] (c-fn [n] (nth coll n))) > ints (range)] > (= (fnmaker4 ints) (fnmaker4 ints))) > => true > > > On Thu, May 5, 2011 at 10:41 PM, Alan <a...@malloys.org> wrote: > >> On May 5, 1:28 pm, Ken Wesson <kwess...@gmail.com> wrote: >> > On Thu, May 5, 2011 at 4:16 PM, Alan <a...@malloys.org> wrote: >> > > (let [fnmaker4 (fn [coll] (fn [n] (nth coll n))) >> > > ints (range)] >> > > (= (fnmaker4 ints) (fnmaker4 ints))) >> > >> > > You want to make it impossible to compare functions that close over >> > > infinite sequences? What is the point of being able to compare >> > > functions if there are cases in which using the functions will >> > > succeed, and the existing comparison strategy would not cause errors, >> > > but your new proposal does? >> > >> > Hm, that is a problem. You'd need to compare not the sequences, but >> > their generator functions. :) >> > >> > > Similarly, if you try to eval such a function, your proposed function- >> > > eval semantics would, as I understand it, store its closed-over values >> > > in a class constant somewhere. Then there's some secret place holding >> > > onto the head of my lazy sequences for me? No thanks. >> > >> > Your fnmaker4 already holds onto the head of ints, above, so that this: >> > >> > user=> (def q (fnmaker4 (iterate inc 0))) >> > #'user/q >> > user=> (q 119) >> > 119 >> > user=> (q 0) >> > 0 >> > >> > can work properly. >> >> Right. But if I drop all references to the returned function after I'm >> done with it, it gets GCed. If there's some class holding a reference >> to it forever, it will never get cleaned up. For example, ((fnmaker4 >> (range)) 1e6) will (I think?) currently result in a million ints being >> held in memory at once, as things are now. Those things will get >> thrown away shortly thereafter, though. I'm not sure I fully >> understand your proposal, but it seems to me like you might be making >> these stick around permanently if I include the right mixture of eval, >> quoting, and unquoting in that expression. >> >> -- >> 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
