The way most parser generators work is that you can attach arbitrary pieces of code to be run at certain points during parsing. Usually you use this to build up your abstract syntax tree (AST). No information (except perhaps things like comments and whitespace if you don't need to preserve them) needs lost when you convert the source code to an AST. Usually you would also include in the AST useful metadata like the line and character positions particular expressions came from so that when displaying an error you can easily point out the location of the problem.
If the language is simple enough, instead of building an AST you could directly emit byte-code (or directly do analysis) from within the parser, but doing so limits what you can do rather a lot. For example many compiler optimizations are transformations applied to the AST before code generation happens. Liam <liam.ga...@gmail.com> writes: > I wrote: […] sophisticated syntax based evaluation or inferences from > “cold code” [...] not node. > > This is just my personal language in referring to evaluating code from > its parse tree. In my mind, code when on the screen being edited: it > is cold. But when run through the clojure compiler: it is hot. My > understanding of programming is completely intuitive not formally > taught. I would imagine most analysis/refactoring tools work primarily on an AST. If they need to do something with the raw text they would just have the parser include enough information in the AST that they can reproduce the source exactly. Alternatively, for something fairly simple like method renaming in static language, they could just store the start and end locations in the text of every method name node. Then they search the AST looking for method names, pull out each of their start and end locations and do the appropriate replacements in the text. I don't think using a parser generator really limits you in any way unless perhaps you have really odd syntax rules [1]. Even then you could likely use a generator for most of the normal syntax and 'plug in' some custom code for just the bits that aren't statically parsable. [1] http://www.perlmonks.org/?node_id=663393 -- 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