Re: Re: software design clarification

On Wed, 2007-05-02 at 10:10 -0400, Stefan Seefeld wrote:
> The parse tree is really only a superstructure on top of a source buffer,
> i.e. all leaf nodes of the tree point into actual source code. The way
> the PTree as well as the Buffer collaborate make it possible to apply
> local changes to the code, and then write it out again, leaving all
> unchanged code intact, preserving everything, down to formatting.

Oooh!  I wrote an XML parser once that could do that for the very same
reason.  That's pretty neat!

> Yes indeed, and it will definitely be available in a separate representation
> (since the parser needs to do that work anyway). All I'm saying is that it
> shouldn't be an integral part of the parse tree, for modularity.
> 
> For example, imagine a parse tree together with a dictionary mapping
> parse tree nodes to declarators (the latter should become part of the
> symbol table representation). That's all that is required in order to
> traverse the parse tree, identifying connections from variable / type name
> uses to their declaration.

That makes sense.  I was thinking symbol table for a bit.  And the
problem there is a given identifier name may refer to a lot of different
possible entities depending on the context in which that name appears.
But if you map the parse tree nodes those identifiers appear in to
declarators, that goes away.

As a random aside, you could save a ton of space in memory by using
'intern' on the strings representing identifiers and/or keywords.  I was
once working on something that sucked in several million rows of
database and managed to significantly curtail memory usage through
creative use of interned strings.  I believe it may also have made
things faster as it turned the typical worst case for string compares of
the strings being equal into the best case (compare pointers and
discover they're equal).

> However, I'd like to take this occasion to point out that the symbol table
> isn't complete yet, and that I'd would very much appreciate any help in that
> work.

*grin*  I might.  I put the probability at about 5-10%.

I've never actually downloaded Synopsis and even tried to use it.  I've
been waiting until I was reasonably confident I could throw it at the C
++ code I've written over the years and have it work.  :-)  So I just
keep tabs on the progress of things and pop into discussions that seem
interesting.

But, if helping out is required for it to exist or would push it forward
faster, the problem of documenting my C++ code nicely might be enough of
a hook to get me interested in doing something.

Thanks,
-- 
The best we can hope for concerning the people at large is that they
be properly armed.  -- Alexander Hamilton
-- Eric Hopper ([email protected]  http://www.omnifarious.org/~hopper) --

_______________________________________________
Synopsis-devel mailing list
[email protected]
http://lists.fresco.org/cgi-bin/listinfo/synopsis-devel

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBGOefNjtsvlOwvazYRAp0LAJ40YomJFSuY++gt/w9XShRHOpDDAACg2Ntp
CMXxXg4DP/KPAR0+/DJM/ew=
=0Aky
-----END PGP MESSAGE-----