Pull scope handling out of EDG/Sage III translation so that is is made available to anyone else building the Sage III IR from scratch (which when it gets non-trivial, involves the manipulation of scopes).
Other stuff ...

File graphProcessing.h

utilize BOOST visitors to take advantage of the BOOST graph structures abilities

*One improvement that should be implemented ASAP is changing the algorithm from a recursive algorithm to an iterative algorithm. Keeping the memory requirements down is much easier in this form and would probably increase the size of graph that the algorithm can handle.

*Another improvement that should be implemented when possible is to allow for loop analysis. This could be implemented by simply running the algorithm on the loop, but there would need to be a provision that kept the algorithm from stopping as soon as it starts. This could be done by separating the node into two nodes, one with all the inedges and one with all the outedges. OR one could collect the loops when they are deleted (the whole loop is calculated necessarily), though nested loops would have to be considered further in order to find a way to deal with them.

*It is possible that graph matching algorithms might prove useful to distinguish different types of graphs contained within the CFG and optimize traversal over them. Look up graph matching algorithms or pattern matching (potentially) for more information on such algorithms, though I do not believe there is an existant literature on matching subgraphs for this purpose.

*The parallelism in this program should be optimized by someone experienced in parallelization optimization

Group localNodeQueryLib

Finish documentation!

Member mangleExpression (const SgExpression *expr)

Find a better way to deal with general template expression arguments.

Class PDFGeneration

Finish documentation!

Group PDFGenerationStuff

Finish documentation!

Class PDFInheritedAttribute

Finish documentation!

Group queryLib

1. Finish documentation!

Make the source code directory structure for Query lib match the documentation.
Make the library more exstensible (perhaps designed like the PDF and DOT libraries).

Page ROSE AST Copy Mechanism

Most types are shared, but named types are copied, and the copies need to have there declarations reset to the new AST.

base class modifiers are shared and this should be fixed.

Friend function in classes are not represented by symbols in the global scope. Not that this is always the rule, it is the default for ROSE and it is setup inconsistantly in the generated AST copy. See copytest2007_39.C.

copytest2007_46.C is too difficult to figure out (likely because the SgTemplateArguments are shared).

copytest2007_47.C is too complex and likely demonstrates an error.

copytest2007_49.C is too complex and likely demonstrates an error.

Group ROSE_ProgramTransformationGroup

Add Constant folding since we currently unfold all folded expressions in the code generation phase. This would be something that could be verified as well since it EDG has also computed the constant folded result and we have stored that explicitly as well as the expression tree from which it was folded. The proposed constant folding would also work on AST fragments constructed explicitly in ROSE from lower level mechanisms.

The ROSE source code might be easier to organize if we have an include directory just for the included files from the transformations. Then use separate directories for the implementations (we want to always separate the implementation if possible from the header file and place it in a separate file. This would make it easier to add transformations and make the maintenance of the development tree a bit easier. As it is each new directory forces a new include path to be specified and a new library to be generated (in /config/Makefile.for.ROSE.includes.and.libs).

Member SageInterface::appendArg (SgFunctionParameterList *, SgInitializedName *)

function type , function symbol also need attention.

Member SageInterface::get_C_array_dimensions (const SgArrayType &arrtype, SgInitializedName &initname)

make initname const

Group Scope stack interfaces

consider complex cases:

how many scope stacks to keep? one. examine only one transparently
regular: push a child scope of current scope, add symbols etc.
irregular: push an arbitrary scope temporarily, add some symbol, then pop
even push a chain of scopes
restore scopes

Group Scope stack interfaces

consider complex cases:

how many scope stacks to keep? one. examine only one transparently
regular: push a child scope of current scope, add symbols etc.
irregular: push an arbitrary scope temporarily, add some symbol, then pop
even push a chain of scopes
restore scopes

Group Scope stack interfaces

consider complex cases:

how many scope stacks to keep? one. examine only one transparently
regular: push a child scope of current scope, add symbols etc.
irregular: push an arbitrary scope temporarily, add some symbol, then pop
even push a chain of scopes
restore scopes

Class Sg_File_Info

isOutputInCodeGeneration() is orthogonal to isCompilerGenerated and isTransformation(). Currently IR nodes that are marked as isTransformation() are output, but these need to be marked as also being isOutputInCodeGeneration() so that orthogonality of the concepts is maintained.

It is possible to call get_file_info() on a SgFileInfo object and this needs to be fixed because it does not make any sense. This is because get_file_info is defined as a virtual function on SgNode. Not sure this is a great design, but maybe it just needs a local implementation of a private get_file_info() member function so that it can't be called (can be hidden).

Should there be a simpler way to copy a SgFileInfo object than: "new Sg_File_Info(*fileInfo);" or "fileInfo->copy();"; likely not!

Define the subset of IR nodes which would all have:

Sg_File_Info
AstAttributeMechanism
SgNode (parent pointer)
This will make the documentation more intuative. The argument supporting this is that we operate on those IR nodes that correspond to the visual representation of the source code (so we can exclude SgSymbols, and SgTypes). Having the same subset of IR nodes permits a simpler documentation of the API and intuition as to where it applies. A likely subset would be:
SgLocatedNodes
SgFile
SgDirectory (questionable)
SgInitializedName
SgBaseClass
SgTemplateArgument
SgTemplateParameter

Remove the functions: isCompilerGeneratedNodeToBeUnparsed(), setCompilerGeneratedNodeToBeUnparsed(), and unsetCompilerGeneratedNodeToBeUnparsed() from where they are called.

Consider putting the endOfConstruct information into the single Sg_File_Info object. Currently the SgLocatedNode stores two Sg_File_Info objects, one for the beginning and the end of each construct. This would save significant space in the AST. Additional information in the Sg_File_Info could be:

offset from starting line number to the end of construct
flag for if end of construct is located in the same file as the start of construct

Consider using "short int" instead of "int" for the file_id, line, and col (and maybe the classificationBitField) to reduce the size of the data structure. Padding is not a significant issue since data structures are allocated in contiguious memory (except for padding to at least the nearest byte if bit field widths are used.

Member Sg_File_Info::hasPositionInSource () const

figure out what this does, it appears to be called in two places (attachment of comments and CPP directives (attachPreprocessingInfo.C) and marking template specializations for output (markTemplateSpecializationsForOutput.C)).

Class SgAsmStmt

This should not be a SgDeclaration (should be a regular SgStatement). Where "asm" is used in declarations (e.g. "int x asm("ax") = 0;") this is a SgVariableDeclaration. A asm statment is really just another kind of statement (e.g "asm ("template",output operand, input operand);"). This sort of statement is not a declaration (as I understand it). This will be fixed in a later release.

Class SgAssignInitializer

Double check the accuracy of this description.

Class SgBoolValExp

The name "SgBoolValExp" should be "SgBoolVal" to be consistant with the names of all other classes derived from SgValueExp.

Class SgClassNameRefExp

Need to figure out some examples of whare this is used.

Member SgConstructorInitializer::p_associated_class_unknown

Enforce p_declaration is valid pointer when p_associated_class_unknown is false within AST consistency tests.

Class SgDeclarationStatement

Current issues to look at:

Current classes derived from SgDeclarationStatement and the SgInitializedName class have ways of generating names, qualified names, and mangled names, but we lack a uniform mechanism to generate mangled qualified names. The implementation is not uniform within the IR and this is a problem for applications which must generate unique names for C++ constructs. Specific to functions names:
- We have:
  1. get_name()
  2. get_qualified_name()
  3. get_mangled_name()
- While we need (on ALL SgDeclarationStatement IR nodes):
  1. get_name()
  2. get_qualified_name()
  3. get_mangled_name()
  4. get_qualified_mangled_name()

Class SgDeleteExp

I believe we can associate the destructors from the class with delete operators.

Member SgDeleteExp::p_need_global_specifier

Check if this bool data member is used and/or required.

Class SgDirectory

Consider adding a SgFileInfo data member to be uniform with SgFile.

Class SgDoubleVal

Add string to this class so that the exact value can be held in the AST.

Class SgDoWhileStmt

The conditional test should be an expression (different from a SgWhileStmt), see test2005_114.C for examples and details.

Member SgDoWhileStmt::p_condition

This should be changed to be a SgExpression (to follow the C++ standard). We also have the condition specified before the body within the ROSETTA specification and this causes the traversal to travers the condition and body in the wrong order (for do-while, the traversal should be body forst and condition second). See test2005_114.C for more details and example code (example of strange loops).

Class SgExpression

Consider placing the VARARGS expression nodes into a common base class derived from SgExpression.

I have removed the access functions from the explicit storage of type information in SgExpression objects as phase 1 of a 2 phase approach to eliminate the storage of the type in the SgExpression IR nodes. This type should be computed where required. This would avoid it being held redundently. This mechanism is being redone internally. Some IR nodes will have likely have to store there type explicaitly (function expressions for example, though it might be better computed through the symbol). It is not clear it this computing of the type will be better than stroing of the type explicitly. It might be required for SgBinaryOp IR nodes to store the type if it is not clearly from either the lhs or rhs (if no simple rule exists).

SgScopeOp is deprecated and will be removed in a future version of ROSE. It is a hold over from support for CC++ which is not supported in SAGE III anymore.

SgRefExp is deprecated and will be removed in a future version of ROSE. It is not used anywhere within SAGE III and I don't know why it is there.

Need to find an example of where SgClassNameRefExp is used. It is build in the EDG/Sage III translation, but not in a way that it is obvious that it is still used within Sage III. So this may have to be removed at a latr date.

To support Fortran parser we need an IR node which will represent the ambiguity of an array access or function call expression. These are then resolved within the AST after parsing (requires AST Fixup rule).

Fortran support requires support for function call using: "foo(temp=*<label>)" this might force the development of a label expression to support this. Code using this compiles with gfortran, so it appears to be F90.

Class SgExprListExp

Consider that get_type() returns a SgDefalutType and should return the SgType associated with the last expression in the list.

Class SgFile

The ROSEAttributesListContainerPtr p_preprocessorDirectivesAndCommentsList should be implemented a list instead of a pointer to a list. This might require a list copy in the internal hand,ing, but would simplify the design and there is not the same memory constraint of having a pointer to a list vs. a list here because the list is almost always valid (most source code incluses at least one comment or CPP directive) and there is only one SgFile object per source file (so there are relatively few SgFile nodes in even a very large AST).

This IR nodes now has a Sg_File_Info pointer, however it needs to be made consistant with the filename that is returned from SgFile::get_fileName().

The default constructor for SgFile sets the SgGlobal pointer to NULL and perhaps it would be better if it set it to a valid SgGlobal object then we would have a better defined empty list of declarations.

Yarden has suggested we provide a way to modify the link line that would be generated to support the backend compilation. I think we should have a list of strings that could be added to the link line (appended to the end would be the simplist). Else we need a virtual function that could be overloaded to customize the control over the link command generation (however we want to discourage the derivation of user defined IR nodes from existing IR nodes since this would break some of the internal mechanisms that use the memory pools).

Class SgFloatVal

Add string to this class so that the exact value can be held in the AST.

Class SgForInitStatement

Evaluate if this should be derived from SgSupport, like other "list" based IR nodes.

Evaluate if we should even have this IR node. If the SgVariableDeclaration were to be fixed to really use the list of SgInitializedName objects where multiple variables are declared in the same variable declaration then we might not need this (I think). And if it didn't exist it would make the use of the SgForStatement a little bit simpler.

Class SgForStatement

The conditional in this test is currently an expression, but should be a SgConditional or a SgStatement (e.g. so that it can be a variable declaration).

Now that the test is a SgStatement, perhaps the name of the field should be "test" instead of "test_expr".

Member SgForStatement::p_loop_body

Change "loop_body" to "body" to be consistant with other scopes that contain a SgBasicBlock.

Class SgFunctionDeclaration

Need to mark function declarations appearing in the file rose_edg_required_macros_and_functions.h as compiler generated since they are either builtin functions for gcc and g++ or those those builtin function that gcc and g++ required and which EDG fails to include as builtin when compiling with EDG's GNU_COMPATABILITY_MODE (current default for ROSE).

Need to better handle fiend injection rules, currently the SgFunctionSymbol for a friend function is placed into the global scope. It likely should be the outer scope for a non-defining declaration and the class scope for a defining declaration. But the exact rules for this are more complex. So the location of the SgFunctionSymbol in the symbol table of SgGlobal is a poor approximation.

Class SgFunctionParameterList

Check scopes of variables in function parameter list, should point to function definition, if the function definition exists, else they are undefined. If they are undefined then we still have to have something for them to point to, we could propose that this be the scope of the function declaration (I think this is what is done). The test in the tutorial tests this and it seems to be correct.

Not clear if this should be a declaration statement (might make more sense derived from SgSupport, or perhaps from SgLocatedNode (with other IR nodes that are currently derived from SgSupport, see SgLocatedNode for details).

If this should be a SgDeclarationStatement (and there is a reasonable argument for this) then perhaps the declaration containing any default parameters should be the defining declaration, independent of the defining declaration of the associated function declaration.

Class SgFunctionRefExp

Figure out why SgMemberFunctionRefExp is required instead of just SgFunctionRefExp.

Make the use of a SgMemberFunctionSymbol in a SgFunctionRefExp an error. The result will not unparse correctly (suggested by Jeremiah).

Class SgFunctionTypeTable

Evaluate if this should be derived from SgSupport (consistant with SgSymbolTable).

Evaluate if we might like to have the p_function_type_table be a SgSymbolTable rather than a pointer to a SgSymbolTable (see implementation note).

Class SgGlobal

Cleanup interface which presently has multiple append,prepend, insert functions. It might be best to eliminate them and use STL directly.

Class SgIfStmt

The unparse function "unparseIfStmt" associated with this IR node is implemented using a loop. I think this should be changed to be more conventional and structural (consistant with the design of the rest of the unparsing).

Class SgLabelStatement

Review if we want to have the label statement reference it's associated statement (it would be a redundent reference, since the next statement is already in the list of statements for the scope).

Class SgLocatedNode

The AstAttributeMechanism type should be handed as other IR nodes with it's own memory pool, except that in all cases where it would be used, it would be a base class to a user-defined derived type and thus would not fix in our memory pool.

Consider name change of "SgLocatedNode" to "SgSourceNode".

Consider moving some of the IR nodes currently in SgSupport to this IR node. IR nodes that might be moved would include:

Class SgLongDoubleVal

Add string to this class so that the exact value can be held in the AST.

Class SgModifierNodes

Fortran support for modifiers is required: see section 5.2, 5.3 in Fortran 2003 standard. Note that type modifiers can be used as statements.

Class SgName

Define a string conversion operator so that we can handle "SgName name; string s = name;" This would start the process of internally having SgName contain a C++ style string.

Change SgName to store a C++ style std::string, instead of a C style char*.

Some of the member functions defined in this class will be removed (head(), tail(), etc.) because they represent low level string handling which is best done on a C++ style string more directly using C++ string operators.

Class SgNamespaceDeclarationStatement

Consider having a function which could generate a list of all the SgNamespaceDeclarationStatement IR nodes that match the same namspace. This would make a good first project for a new student.

Include a graph to show how scopes are handled within the AST.

Class SgNamespaceDefinitionStatement

Cleanup interface which presently has multiple append,prepend, insert functions. It might be best to eliminate them and use STL directly.

Class SgNamespaceSymbol

It might be that we should have a SgNamespaceAliasSymbol so that namespace aliasing can be better supported. We can consider this for future work.

Class SgNewExp

Provide some examples to detail the difference between placement, constructor, and builtin arguments.

I believe we can associate the constructors from the class with new operators.

Member SgNewExp::p_builtin_args

Provide some examples to detail the difference between placement, constructor, and builtin arguments.

Member SgNewExp::p_constructor_args

Provide some examples to detail the difference between placement, constructor, and builtin arguments.

Member SgNewExp::p_placement_args

Provide some examples to detail the difference between placement, constructor, and builtin arguments (these are rarely used in C++).

Class SgNode

The "AstAttributeMechanism attribute;" field should be fixed:

The attribute within this class is not added using ROSETTA and is one of the last (if not the last) variable to NOT be added to the IR nodes using ROSETTA. Because it is not added using ROSETTA, it is a special case (and we hate special cases) in the file I/O (by Jochen) and perhaps elsewhere. This variable should be added using ROSETTA!
Access functions need to be built for the "AstAttributeMechanism attribute;" field and it needs to be moved to be a private data member.
It should be moved to only those IR nodes were it makes sense, e.g. excluded from:
1. SgName
2. SgModifier (and all derived modifier IR nodes)
3. SgUnparse_Info
4. SgSymbolTable
Consider eliminating the set_freepointer() function since only the internal memory allocation mechanisms should use it (and they are forced to access the data member directly since they traverse the memory pools directly and member function can onl be called on allocated object initialized vi the new operator (with a proper constructor call, so that the this pointer is set properly)). Perhaps we don't need access functions for this data member at all.

Member SgNode::unparseToCompleteString ()

This function needs a better name since it is unclear what the "complete" string is.

Class SgOptions

Review if we really want to keep this class.

Class SgProject

Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Implement a "-dumpversion" for compatibility with GNU (icc does the same).

Class SgRefExp

Double check this description.

Class SgReturnStmt

Check that when return (SgReturnStatement) is implicit, it should be marked as compiler generated. Actually we only include returns in the AST which are explicit, so this is not a problem.

Class SgScopeStatement

Where current derived IR nodes from SgScopeStatement contain SgBasicBlock objects, we should consider having them contain SgStatement objects instead of SgBasicBlock. This would avoid current normalizations which are cute, but perhaps unwelcome. We need to discuss and rule on this detail. An alternative would be to let there be a SgBasicBlock and mark it as compiler-generated if it does not appear in the original source code. then the unparser (code generator) could be made to avoid output of the SgBasicblock (and enforce that the number of statements in the block is not greater than one). Effected IR nodes include:

SgCatchOptionStmt (should contain SgStatement)
SgDoWhileStmt (should contain SgStatement)
SgForStatement (should contain SgStatement)
SgIfStmt (should contain true and false SgStatement)
SgSwitchStatement (should contain SgStatement)
SgWhileStmt (should contain SgStatement)
these are currently correct:
SgFunctionDefinition (should contain a SgBasicBlock)
SgGlobal (constains a list of declarations (SgDeclarationStatement objects))
SgNamespaceDefinitionStatement (constains a list of declarations (SgDeclarationStatement objects))
SgClassDefinition (constains a list of declarations (SgDeclarationStatement objects))

Member SgScopeStatement::generateStatementList () const

This runtion should return a const value so that it would be more clear that it could not be modified (since such modifications would not be reflected in the AST).

Class SgSizeOfOp

Need to implement support in EDG/SageIII translation for this operator.

Class SgStatement

There are a number of statements that contain a SgBasicBlock where they should contain a SgStatement. In each case changing the data member to be a SgStatement will unfortunately change the constructor parameter list and thus the ROSE API. So these changes have to be organized a a point where it is clear we will be changing some details of the ROSE API (prior to external release). Problem IR nodes are:

Fortran support for modifiers can be used as statement (must be added to IR): see section 5.2, 5.3 in Fortran 2003 standard. Note that type modifiers can be used as statements.

Fortran support requires statements in section 6.3.

Fortran support requires for "where" and "forall" statements.

Fortran support requires for case statement ranges (gnu extension for C, but standard in Fortran).

Fortran support requires statements in section 8.1.4, 8.1.5.

Fortran support requires statements in section 15 (modifiers for ISO_C_BINDING).

Class SgSwitchStatement

FIXED: The conditional test should be a SgStatement so that a declaration can be used, it is currently an SgExpression (specifically a SgExpressionRoot).

The body of the SgSwitch should really be a SgStatement not a SgBasicBlock. DuffsDevice can be modified to should an example of this but there are also much more trivial examples. See comment about this in the SgStatement todo list.

Class SgSymbol

Consider derivation of SgEnumSymbol, SgClassSymbol, and SgTypedefSymbol from a common SgTypeSymbol. Then supporting functions for SgTypeSymbol would lookup any of these type based symbols.

Class SgSymbolTable

The rose_hash_multimap should perhaps be included as a data member instead of implemented as a pointer. We should consider this detail.

We should decide if we want to give Symbol Tables a name or not, it seems that we rarely if ever do this so perhaps we should not have such a field.

Member SgSymbolTable::p_no_name

generate a list of instances where symbols don't have names. (Namespaces don't have to have a name for example).

Class SgTemplateArgument

Move this be a SgLocatedNode since it should have a position in the source code.

Class SgTemplateDeclaration

Template declarations marked as friend don't seem to be marked as friend internally.

The scope of a SgTemplateDeclaration should be a SgTemplateInstantiationDefn, since it could be associated which more than one definition. What we need, and don't have yet, is a SgTemplateDefinition to accompany the SgTemplateDeclaration then a SgTemplateDeclaration could have a SgTemplateDefinition for a parent and or scope when it is a member function or namespace or global scope (typically), otherwise.

Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Member SgTemplateDeclaration::p_string

Check the accuracy of this statement in the unparser!

Class SgTemplateInstantiationDecl

Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgTemplateInstantiationDirectiveStatement

Consider tranversing instantated templates instantiated by an explicit instanntatiation directive.

Class SgTemplateInstantiationFunctionDecl

Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgTemplateInstantiationMemberFunctionDecl

Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Class SgThrowOp

Make the "*PtrList" typed objects non-pointer data members (lists) instead of pointer to lists.

Consider that get_type() returns a SgDefalutType and should return the SgType associated with the last expression in the list (research details of the list of pointers in the C++ throw operator).

Class SgType

Several classes derived from SgType are not used and can be removed:

SgTypeUnknown (Used by SageInterface to specify references to undeclared variables)
SgUnknownMemberFunctionType

The signed types (except for signed char) are not used in SAGE III and do not exist in C or C++. These IR nodes should be removed, specifically SgTypeSignedShort, SgTypeSignedInt, SgTypeSignedLong.

For Fortran support we need to add the kind, length data member to specify the width. To support handling of kind, length parameters we should use the information about the target backend compiler and map kind information to bit widths (not a high priority).

Labels appear to be used as types in "foo(*,*)", see example from Chris (LANL, 4/19/2007).

Class SgTypedefDeclaration

There are a few data members in this field that don't appear to be used (should be removed if not required):

p_declaration: have not seen it be used anywhere (I think it is used when a declartion is explicit in the typedef, check this out, might be part of older mechanism before defining and nondefining declarations were developed to provide a uniform mechanism for all declarations)
p_parent_scope: this is a SgSymbol, but I don't know why it is stored explicitly.

Member SgTypedefDeclaration::p_parent_scope

We can remove this.

Member SgTypedefSeq::p_typedefs

It might be better for this to be a list of SgTypedefTypes

Think about if we could also store a reference to all pointers and reference types where they share a common base_type.

Member SgUnaryOp::p_expression_type

This value is only used for the SgCastExp, we will move it to that IR node when we are ready to change the interface for the SgExpressions (and SgUnaryExp IR nodes).

Class SgUsingDirectiveStatement

Explain difference between using declaration and using directive.

Class SgValueExp

We should add a SgComplexValue IR nodes for C99 support of complex constants. At the moment these are internally represented as SgFloatValue, SgDoubleValue, or SgLongDoubleValue IR nodes.

Class SgVariableDeclaration

Finish explaination of variable declaration, relationship to variable definition, and the scope issue.

template static variable declaration are instantiated and this is at least sometimes an error (at least when not part of a transformation). See test2005_69.C for example of this problem.

Member SgVariableDeclaration::p_variableDeclarationContainsBaseTypeDefiningDeclaration

Provide an example of where p_variableDeclarationContainsBaseTypeDefiningDeclaration is true and where it is false.

Class SgVariableDefinition

If a SgVariableDefinition is built internally as part of a SgVariableDeclaration it should be marked as compiler generated if the "extern" keyword was not used in the SgVariableDeclaration. This needs to be looked into.

Constant folding happens when the bitfield is a variable and the variable name is lost. This IR nodes needs to be modified to alternatively store the associated SgExpression (in case it is a root of an expression tree).

Class SgVariableSymbol

Need to figure out if it is such a great idea of a single symbol to be in two scopes or if it would be better to use two different symbols (since there are two different SgInitializedName object built (the last one referencing the previous one through the p_prev_decl_item pointer)).

The get_type() function can return NULL when the get_definition() is NULL. I think we should have assertiosn to make sure that get_definition is a valid pointer and that get_type() should not return NULL.

Class SgVarRefExp

Test to verify that each variable reference is associated with the inner most scoped variable with that name, except where name qualified. Applies most easily to local variables. The same test could be used for function references, actually all references.

Make sure that declarations appear before variable references.

Class StringUtility

Finish documentation!

Group subtreeQueryLib

Finish documentation!

Group transformationSupportLib

Fixup interfaces in Sage III using code from the TransformationSupport class.