> 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) 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)) 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 -- 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
