|An interesting Parser problem firstname.lastname@example.org (email@example.com) (2007-11-29)|
|Re: An interesting Parser problem firstname.lastname@example.org (2007-11-30)|
|Re: An interesting Parser problem DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-11-30)|
|Re: An interesting Parser problem email@example.com (Holger Siegel) (2007-11-30)|
|Re: An interesting Parser problem cfc@shell01.TheWorld.com (Chris F Clark) (2007-11-30)|
|Re: An interesting Parser problem firstname.lastname@example.org (Gene) (2007-12-02)|
|Re: An interesting Parser problem email@example.com (RLW) (2007-12-08)|
|From:||firstname.lastname@example.org (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)|
|Date:||Fri, 30 Nov 2007 09:35:05 +0100|
|Organization:||Department of Computer Science, University of Copenhagen|
|Posted-Date:||30 Nov 2007 20:33:29 EST|
"email@example.com" <firstname.lastname@example.org> writes:
> So we need to construct a parse tree of the input. But after editing,
> we want to conserve the comments and white space as much as possible
> so that the user does not see drastic changes to original code.
> One approach is to store to file name and offset information of each
> token in the parse tree. During decompiling, text between two offsets
> is copied as such from original file if its not edited. If edited,
> then the new text is used.
An alternative is to store leading whitespace and comments as an extra
attribute to every lexical token. When you build the abstract syntax
tree, you can combine the whitespace attributes of the tokens and the
text of the keywords etc. that appear in a production into a single
format string, e.g., " if (%s) %s\n else %s", so printing the syntax
tree is done by first creating strings for subtrees and then using the
format string to combine them into a single string.
Return to the
Search the comp.compilers archives again.