On Tue, May 15, 2012 at 12:51 PM, Timothy Baldridge <tbaldri...@gmail.com> wrote: >> I can certainly imagine cases where the analyzer might want >> reflection on types etc of the given platform, but I think that is >> really an optimization, trading off compile/analyzer time reflection >> for runtime reflection. That platform reflective information would be >> provided by something like clojure.reflect, and could either run via >> querying a running instance of the platform, or via just a static data >> file of the information. But that info is, I think, mostly required to >> make generated code fast, but it should be possible to generate slower >> reflective code "generically" for the initial bootstrap without it. > > The real reason this is done, is because Clojure is a compiled > language. For instance: > > user=> (defn z [baz] baz) > #'user/z > user=> (defn foo [] (z.)) > java.lang.IllegalArgumentException: Unable to resolve classname: z > (NO_SOURCE_FI > LE:10)
I dunno what the defn z above is supposed to demonstrate. the analyzer result for (z.) would be something like "this is code creating an instance of a type named 'z' in the namespace 'foo without arguments, it doesn't reference any locals" > The other thing I'm starting to wonder is what doing all the above > really gets us? > > For instance, let's say the analyzer sees this function: > > (defn as-str [x] (.toString x)) . is an interop form, the analysis would result in something like "call the interop toString on the local x, dunno what type x is" > That can't port to Python, or really any other VM besides JS. So if > we're looking at translating the analyzer itself we have to develop > some sort of base set of libraries that every thing else can build > upon. So either we need to define a ur-clojure function called > "toString", and then every emitter will need to implement that > seperately. > > At that point, I have to wonder what's the point of this "analyzer" > step? In Clojure code is data is code. The more I think about what > this serialized output would look like the more I think it would look > just like Clojure code. What are we actually saving with this process? > > Timothy the point of the analysis step is to generate a richer (more verbose) set of information about the code, there is a lot of information you would like to have when compiling (for example, for some platforms it would be nice to know at the start of a function what locals exist in the that function, or what locals it closes over) which are extractable from the regular clojure data that represents code, but it's takes an annoying amount of repetitive work to do so. This is not to say you might not end up with a platform specific analyzer (which would kind of be a shame, because I can imagine a library of platform agnostic optimizers that run over analyzer output), just a place to start from when bootstrapping. > -- > 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
