I have been studying and and implementing my own version of LispReader / tool.reader - for the purpose of syntax highlighting and visual token manipulation. My question is this: Why not split this into 2 steps?
1. Reads the input (from PushbackReader et al) and emits a stream of tokens, preserving information about location in source, and applying typing to tokens, if possible. 2. Consumes the stream from step one, descending recursively, applying reader-macros, resolving symbols in name-spaces, etc. This would allow for easier configuration of each step, such as: - turning exceptions on/off (useful for syntax highlighting) - custom reader-macros and custom classes of reader-macros - static analysis of code by controlling the namespacing/context Is there any reason not to do this? (Other than: This is the way it has always been done. This is the way lisp-readers are aways implemented.) Perhaps such a development is already underway? Finally, if I wanted to implement such a solution, would it be to do it in Java or Clojure? Why? -- 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.
