On Wed, May 4, 2011 at 8:16 PM, Ken Wesson <kwess...@gmail.com> wrote: > Closures, including ones whose arguments can't be known until runtime, > can easily be slapped with "implements Serializable" if they haven't > been already. Indeed, an "extends Serializable" on IFn, on top of the > above compiler modification to externalize anything serializable, > would suffice to make it possible to eval (and even AOT-compile) code > containing any embedded function objects, save for closures that have > closed over non-serializable objects.
One more clarification: *any* object could be eval'd. It would just be the case that if you tried to AOT compile code that contained (say, in the output of a macro expansion) a non-serializable, non-print-dupable object or a closure that had closed over one, the AOT compile would fail with a NotSerializableException (and the compiler could catch that and give a more helpful error message pointing to the offending line of Clojure code, so you could track down what object was making the AOT compile fail and fix it, either by replacing the literal object with code to recreate it or by adding a method to print-dup or slapping a Serializable on one of your Java classes or deftypes or whatever). As for concerns that this kind of extension might mask common macro errors, adding some *warn-on-foo* option to generate warnings when "unusual" kinds of object literal were encountered by eval/the compiler would hopefully address such. -- 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
