Re: [Cpptool-develop] Dealing with scope...

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Saturday, November 23, 2002 5:39 PM
Subject: Re: [Cpptool-develop] Dealing with scope...


> On Sat, 23 Nov 2002, Baptiste Lepilleur wrote:
> >
> >     I'd like if you could double check the list of 'scope generator'
> > statement. I've found:
> >
> >     if ( <scopeA )  <scopeB/> else <scopeC/> </scopeA>
> >     while ( <scopeA )  <scopeB/> </scopeA>
> >     for ( <scopeA; ... ;... )  <scopeB/> </scopeA>
> >     switch ( <scopeA ) <scopeB/> </scopeA>
> >     { <scopeA/> }
> >
> >     {
> >         int x =3,<scopeX> y=2<scopeY>;
> >         ....
> >         </scopeY></scopeX>
> >     }
> >
>
> Declarations in if and while statements seem a bit suspicious to me; at
> least they are bad style. The only possible application for me would be
> something like
>
> if (int result = complicatedFunction())
> {
>    process(result);
> };

Assignation in condition statement is not recommended in most C++
guidelines, but it's valid C++ (in fact, there should probably be a
refactoring "ExtractAssignationFromCondition"  or something like that). I
checked with VC++ and you can actually do crazy things like:

if ( int x =3, y = x +2)
    ComputationObject x( x+y );    // this is a new scope

This is indeed bad style, but should be supported.

>
> However, I don't think this is legal since a declaration is not an
> expression. On the other hand, gcc compiles this without any problems or
> warnings.

I believe this to be legal C++ even if it belong to the area of C++ to
avoid.

>
> I have a different (possibly simpler) approach to dealing with scopes in
> finding references to local variables, which I'll describe on the Wiki. In
> short, we can deal with this without introducing scope objects, just
> exploiting the recursive descent behavior of the variable finder.

I think you are underestimating the complexity of matching scope to a part
of the tree. For example, the AST structure of a for statement is:

for ( int x= 1; x < 3; ++x )
    doStuff( x );

[for-statement]
    iteration-property => [declaration-or-expression]            = ( int x=
1; x < 3; ++x )
    iteration-statement-property => [statement]                    =
doStuff( x );

As you can see, the iterated statement is not a child of the for iteration
declaration node. Also, there is no guaranty concerning the order properties
are visited (at the current time they are stored in a vector, which means
you get them in the order they were added, but it is an implementation
detail that we should not depend uppon).

That being said, you're welcome to try, but at least you know what you are
getting into.

As is it, I see a few advantage to the current implementation using scope
object:
- you can 'tag' each local-scope-identifier with a Scope object, allowing
unambiguous reference to temporary variables
- you can search if a identifier already exist in a given scope (validation
of the new temporary name)
- decouple the definition of the scope of each statement from the creation
(that is, the most important stuff are in ScopeGenerator constructor).

On the other hand, it is clear to me that the current scheme will not
survive (without heavy change) dealing with class and method parsing. The
scope of a function member or an attribute declaration is that of all the
class/subclass methods. But this issue does not concern us for now.

On the wiki, you stated that:
> BTW, some of the visitor code should be moved to ASTNode; I'll look into
that.

What are you refering to ?

Baptiste.
>
> Sven.
>
>  --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...