related to this discussion and v. interesting: http://blog.guillermowinkler.com/blog/2014/04/27/decompiling-clojure-iii/
On Tuesday, November 26, 2013 10:04:12 PM UTC, Guru Devanla wrote: > > The important caveat here is "what do we label as data?". If we are okay > with just 'streams of bytes' that will make us understand and reason some > information about the function, then may be the bytecode itself could be > sufficient and could be considered to be data. But, I guess the original > question was regarding data that one could reason in the form on clojure > forms itself. At least, that is what I believe Henry was referring to, > isn't? > > -Guru > > > > On Tue, Nov 26, 2013 at 1:51 PM, henry w <henr...@gmail.com > <javascript:>>wrote: > >> The thing is, the data contained in the source definition is all still >> there in the compiled version - but apparently it is not easily accessible. >> It feels like it must be possible to write a function that looks at a >> function object and it's class and can produce at least a decent >> approximation to the original, or at least a clojure list version of the >> compiled code. No doubt completely faithful recreation wouldn't be >> possible, not least because of macros. >> >> Also, sometimes, such as when developing possibly, it is not always >> necessary to have optimum performance. >> >> >> >> >> On Tuesday, November 26, 2013 8:30:38 PM UTC, Alex Miller wrote: >> >>> Seems like you lost the clojure mailing list in this response, so I >>> re-added it. >>> >>> On Tue, Nov 26, 2013 at 2:09 PM, henry w <henr...@gmail.com> wrote: >>> >>>> Thanks to all respondents. >>>> >>>> This was really just something I was curious about, although I can >>>> think of some practical uses. >>>> >>>> It's just not clear to me still if there is some really good reason >>>> code stops being data (or at least having an accessible data >>>> representation) after it is compiled. Jamie has shown it is still data, >>>> although in a very platform-specific way. Is it just the case that there >>>> aren't compelling use-cases that people have come up with perhaps? >>>> >>> >>> Code stops being data so it can be a more efficient form to the host >>> platform (bytecode), which is what makes Clojure perform well. If you >>> always left the data in the original form, you would just need an >>> interpreter (and Clojure would be much slower). Clojure is always compiled >>> as performance is a key concern. >>> >>> >>>> Pratically, some examples of use might be related to the >>>> https://github.com/clojure/tools.trace library. Here vars are >>>> temporarily bound to functions that are wrapped versions of the functions >>>> they held previously in order to print input and output. A nice >>>> alternative >>>> would be to show the function form with the parameters interpolated. >>>> Another case might be to see not just the source of a function, but to >>>> 'inline' the source of functions called from it. Or just generally mess >>>> about with functions I don't own. >>>> >>> >>> There has been a recent enhancement discussion (perhaps here, perhaps >>> jira, can't find it now) to have functions retain their source definition >>> at runtime. I'm not sure how that would be possible without significantly >>> affecting performance and memory footprint however. >>> >>> >>>> >>>> >>>> >>>> On Tuesday, November 26, 2013 7:01:57 PM UTC, Alex Miller wrote: >>>>> >>>>> It would help to know what your real goal is, but compiled Clojure >>>>> does not retain the original source form. >>>>> >>>>> One hook you do have though is macros which will be invoked prior to >>>>> compilation. At macro execution time, you have access to the special >>>>> &form >>>>> var which is the original form (as a Clojure data structure). >>>>> >>>>> Thus you could write a defn-like macro which when called to define a >>>>> function definition would define the function and decorate it with meta >>>>> that included the definition. I am a poor enough macrologist that I will >>>>> not attempt that here but merely suggest it should be feasible. :) >>>>> >>>>> Alex >>>>> >>>>> On Thursday, November 21, 2013 12:14:39 PM UTC-6, henry w wrote: >>>>>> >>>>>> Say you have a function created like this: >>>>>> >>>>>> (fn [x] (+ x y)) >>>>>> >>>>>> and then you have a reference to an instance of this function, is >>>>>> there some way to use the function reference to access the list '(fn [x] >>>>>> (+ >>>>>> x y)), >>>>>> including the symbol 'y' (such that you could dereference 'y' and get >>>>>> its value)? The source function is not the right thing and so far >>>>>> googling >>>>>> hasn't got me the answer. >>>>>> >>>>>> Thanks >>>>>> >>>>> >>> -- >> -- >> 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<javascript:> >> 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 <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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/d/optout.
