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

Reply via email to