HK1174709B - Creating inferred symbols from code usage - Google Patents

Description

Creating inferred symbols from code usage

Background

Dynamic programming languages perform at runtime the behavior that other (dynamic programming) languages typically perform during compilation if executed. The actions performed by the dynamic language at runtime include: a program is extended by adding new code during program execution, creating objects and definitions, modifying the type system, and so forth.

Dynamic programming languages are typically typed dynamically, meaning that type checking is performed at runtime. In dynamic typing, a type is associated with a value resulting from execution of a program. Dynamic typed languages include Clojere, Groovy, JavaScript, Lisp, Objective-C, PHP, Prolog, Python, Ruby, Smalltalk, late binding in Visual Basic, IronPython, and IronRuby. Dynamic typing is less stringent than static typing, but may result in a greater likelihood of execution errors (e.g., erroneous results due to values of variables having impermissible types). Dynamically typed language systems typically result in less compile-time checking of the source code. Runtime checks can be more complex because they can use dynamic (runtime) information in addition to information that exists during compilation and is still available at runtime. The runtime check predicates stand in on a particular execution of the program and repeat for each execution of the program.

The binding selects which actual operation to use when applying the syntactic operation in the source code. Binding can occur either at compile time (in which case it is referred to as "static binding") or dynamically at runtime (this is referred to as "dynamic binding"). Dynamic binding defers parsing of undefined variables until the program runs. Dynamic binding is different from static binding in that the result, e.g., the meaning assigned to an operation, depends on the runtime type of the actual value it operates on, rather than the compile-time type of the variable in the source code. Typically, statically typed programming languages perform static binding, while dynamically typed programming languages perform dynamic binding. However, when the static language contains dynamic bindings (such as C #4.0 with dynamic language properties) or vice versa, there may be a mix of the two.

Test-driven development refers to an iterative software development technique in which a developer first writes test cases that identify desired improvements or new functionality, then the developer generates code that causes the tests to pass, and then reconstructs the code base to account for any new system requirements. For example, code that includes logic to manipulate an object may be written before the code defining the object is written. In other words: the consuming (consumable) code is written before writing the consumed object.

SUMMARY

The development of dynamic programming techniques and test drivers has at least one mutual challenge. In both cases, tools relying on available underlying code cannot aid the development process, for example, by displaying possible choices for auto-completion when the user types code into a source code editor, since the underlying consumed code has not yet been created. In accordance with aspects of the subject matter disclosed herein, data structures such as syntax trees or semantic trees that include inferred nodes and/or symbol tables that include inferred symbols are created based on the use (or possible use) of the symbols within the overall code. Inferred nodes and/or inferred symbols may be generated by a learning algorithm. The tool may use such created syntax trees or the like to provide information about symbols that have not been created or bound for use in the development of dynamic programming and test drivers.

The data structure representing the source code may be generated by a background compiler during interactive program development. One or more symbols may be added to the data structure based on the source code input into the source code editor, wherein the symbols are inferred from the source code based on usage of the symbols without prior definition of the symbols. The inferred symbol may be created based on applying a set of rules to the undefined symbol. In response to receiving an indication from the user to do so, the inferred symbol may be converted to a real symbol. The conversion of the inferred symbols into real symbols may be triggered by an action of a developer to automatically generate source code based on the inferred symbols. The automatically added source code will include a definition of an undefined symbol. Information associated with the inferred symbol may be displayed in the software development tool in response to activation of an option to enter a "suggested mode" in the programming environment.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Brief Description of Drawings

In the drawings:

FIG. 1a illustrates an example of a system 100 for creating inferred symbologies from code usage in accordance with aspects of the subject matter disclosed herein;

FIG. 1b shows an example of a tree 10 as known in the prior art;

FIG. 1c illustrates an example of a tree 12 in accordance with aspects of the subject matter disclosed herein;

FIG. 2 is a flow diagram of an example of a method 200 for creating inferred symbols from code usage in accordance with aspects of the subject matter disclosed herein;

FIG. 3 is a block diagram illustrating an example of a computing environment in which aspects of the subject matter disclosed herein may be implemented; and

FIG. 4 is a block diagram of an example of an integrated development environment in accordance with aspects of the subject matter disclosed herein.

Detailed Description

Overview

The popularity of test-driven development practices is increasing. Dynamic language effects in programming languages become more prominent. Thus, it may be advantageous for a software development tool to be able to provide information about possible code when a code model does not yet exist or is not yet known but is still consumed. The subject matter described herein makes it possible to create a tool for the first consumption (control-first) programming style that provides relevant information before a symbol exists or is bound.

The subject matter disclosed herein is particularly applicable to writing code having a first-consume or first-test (test-first) development style, and writing dynamic (late-bound) code, although it will be understood that the disclosed subject matter is applicable to any style of computer program development. When writing code, a syntax tree, semantic tree, or symbol table may be created that represents, is based on, or is associated with the source code. For symbols that are not yet bound or defined in the global symbol table, possible or "inferred" nodes or symbols may be created and may be added to the syntax tree, semantic tree, or symbol table created by the compiler.

Multiple candidates for a symbol type may all be possible for the inferred symbol (e.g., the symbol may represent a class or may represent a structure, the symbol may represent a method or may represent an attribute). All candidates may be represented as possible symbols in a tree/table or alternatively a service or software module may be provided to retrieve the set of candidates. As the user continues to write code, the code model may be updated to represent additional information based on the learning model (e.g., using machine learning techniques known in the art). For example, if there is ambiguity as to what the particular inferred symbolic representation exists, as the developer continues to write code, the ambiguity may resolve or a particular choice in the set of choices may become more likely. In this case, the inferred symbols in the syntax tree, semantic tree, or symbol table may be updated to represent the current knowledge state.

The inferred notation may be used by software development tools including, but not limited to, the following: completion lists, call hierarchies, reference lists, object browsers, class views, find references, navigation tools, and the like to provide developer tools for symbols that have not yet been created or bound. In accordance with some aspects of the disclosed subject matter, inferred symbols can be visually distinguished by distinctions such as color, highlighting, by accompanying a particular icon, and the like. The inferred symbol may be included within or made visible within a traditional integrated development environment by activating a particular mode (e.g., by activating a "suggest mode" option). Based on the inferred symbol, an error condition discovered by the compiler may trigger automatic generation of additional source code to correct the error condition. The inferred symbol may be converted to an actual symbol, for example, by activating a "make it true" or "generate from use" option. For example, an inferred node may be converted to a specific node in a syntax tree or semantic tree by activating such an option. Similarly, an inferred symbol in a symbol table may be converted to a specific symbol by activating such an option for the symbol table.

Creating inferred symbols from code usage

FIG. 1a illustrates an example of a system 100 for creating inferred symbols from code usage in accordance with aspects of the subject matter disclosed herein. All or portions of system 100 may reside on one or more computers such as the computers described below with reference to fig. 3. All or some portions of system 100 may reside on one or more software development computers (e.g., computer 102), such as the computers described below with reference to FIG. 4. The system 100, or portions thereof, may include a portion of an integrated development environment (e.g., the IDE 104), such as those described and illustrated below with reference to FIG. 4. Alternatively, system 100 or portions thereof may be provided as a stand-alone system or as a plug-in or add-in.

The system 100 may include one or more of the following: a processor, such as processor 142, a memory, such as memory 144, and a module 106 for creating inferred symbols from code usage. Other components known in the art may also be included but are not shown here. It is to be appreciated that the means for creating inferred symbols from code usage can be loaded into memory 144 to cause one or more processors, such as processor 142, to perform actions attributed to means for creating inferred symbols from code usage 106.

The data structure created or generated by the background compiler based on the input source code may be modified by the module for creating inferred symbols from code usage 106 to include inferred symbols created by the module for creating inferred symbols from code usage 106. The inferred symbol may represent consumed code, where the consumed code is present in the source code when the consumed code is not present in the source code. In accordance with aspects of the subject matter disclosed herein, the module for creating inferred symbols from code usage 106 can create one or more inferred symbols 108 based on consuming code entered into an editor 110.

The editor 110 may represent a source code editor associated with a back-end compiler 116, wherein the back-end compiler 116 generates a syntax tree, semantic tree, or symbol table of real symbols when a user inputs source code. In accordance with aspects of the subject matter disclosed herein, the module for creating inferred symbols from code usage 106 can add or modify one or more inferred symbols 108 to a syntactic tree, semantic tree, or symbol table of real symbols created by the compiler 116 based on the code input into the editor 110. Further, the module for creating inferred symbols from code usage 106 may generate source code based on the inferred symbols, as will be described more fully below. The tool 112 operating on real symbols 114 may be arranged to additionally or alternatively operate on inferred symbols 108.

The module 106 for creating inferred symbols from code usage may include or incorporate one or more of the following: a compiler, such as a background compiler, a parallel compiler, or an incremental compiler; a parser, such as a background parser, a parallel parser, or an incremental parser; or a plug-in, preprocessor, or accessory; or an extension to an IDE, parser, compiler or pre-processor. The module 106 for creating inferred symbols from code usage may be separate from or associated with: a compiler, such as a background compiler, a parallel compiler, or an incremental compiler; a parser, such as a background parser, a parallel parser, or an incremental parser; or a plug-in, preprocessor, or accessory; or an extension to an IDE, parser, compiler or pre-processor. The module 106 for creating inferred symbols from code usage may be associated with, incorporated into, or separate from program development tools including, but not limited to: completion list, call hierarchy, reference list, object browser, class view, find reference, and/or navigation tool. The module for creating inferred symbols from code usage 106 may convert one or more inferred symbols to real symbols in a symbol table, syntax tree, or semantic tree.

Editor 110 may be a source code editor supported by a back-end compiler that generates semantic and/or syntax trees when a developer or user writes source code. For example, assume that the user writes the following:

a background compiler, known in the art, may generate the syntax tree 10 shown in fig. 1b when a developer inputs code into a source code editor (e.g., editor 110 of fig. 1 a). The syntax tree 10 is an example of the data structure of the real symbol (i.e., the real symbol 114) shown in fig. 1 a. In response to declarations of class Bar and class Engine, respectively, represented by the following code lines, the syntax tree created by the back end editor includes a node of class Bar and a node of class Engine:

public class Bar{…}

and

public class Engine{

}

in accordance with aspects of the subject matter disclosed herein, the module for creating inferred symbols from code usage 106 creates an inferred node for the method "Start". When the module for creating inferred symbols from code usage 106 detects the following statements:

e.Start()；

the module for creating inferred symbols from code usage 106 derives: a declaration of method start is required. Referring now to FIG. 1c, a module 106 for creating inferred symbols from code usage creates an inferred node (i.e., node 14) for method start in tree 12. The inferred nature of the node is depicted in FIG. 1c by the dashed line of node 14. Once the inferred node has been added to the syntax tree, the inferred node may be used by tools 112, including but not limited to: completion list, call hierarchy, reference list, object browser, class view, find reference, and/or navigation tool.

For example, once the inferred node has been added to the syntax tree, if the developer were to type "e" in his code, one of the options presented to him by the autocomplete tool may be "Start". Further, if an inferred node has been added to the syntax tree, the inferred node may become a permanent part of the syntax tree by activating "make it true" or "generate from use" options available from tools such as, but not limited to, tools that associate information and actions with entered information (e.g., action tags). In response to rendering the inferred node genuine, source code can be generated according to a set of heuristics. For example, in response to having the method Start node true, the following source code may be generated:

public void Start(){

}

activation options may be provided in the programming environment that allow inferred nodes to be visible or referenced in available tools.

The inferred symbols created by module 106 for creating inferred symbols from code usage may be created based on the application of a set of rules, as described more fully below with reference to FIG. 2.

FIG. 2 illustrates an example of a method 200 for building an inferred syntax tree from code usage in accordance with aspects of the subject matter disclosed herein. At 202, a module for creating inferred symbols from code usage monitors code input into a source code editor supported by a background compiler. In response to detecting the absence of consuming code to consume the code, the module for creating inferred symbols from code usage applies the provided heuristics at 204 to create one or more inferred symbols at 206. The created inferred symbols include inferred symbols added to a symbol table, inferred nodes added to a syntax tree, or inferred nodes added to a semantic tree.

The heuristics may include a set of defaults. For example, in the following cases: the symbols may represent classes, interfaces, or structures of which are part, and one or more rules may provide a mechanism for deciding what type of symbol the inferred symbol represents. For symbols representing methods with different sets of parameters, the rules may determine: the method parameters are either consolidated into a small set of overloads of a single type, or into a broader set of overloads of multiple types, or in between. For example, using the example above, if parameter 3 is passed to method e.start, it may be determined that: method Start uses integer parameters. If the string is passed to e.start at other locations in the source code, it may be determined that: there are two methods, called Start, one with strings and the other with integers. Heuristics may be set to determine: the inferred symbol is generated by default with minimal access (e.g., "private") or with public access. With respect to determining whether an inferred symbol is a class or an interface, it may be possible to determine by the surrounding language: whether a particular inferred symbol is an interface or a class. For example, the statement:

Engine e=new Engine()；

an engine is identified as a class rather than an interface because the statement creates a new constructor for the class engine and it is known that interfaces cannot be constructed directly.

Once the inferred symbol has been added to a data structure (e.g., a syntax tree, semantic tree, or symbol table), various options may be available to the user. For example, selecting an option (e.g., a "make it true" or a "generate from use" option) may trigger automatic, compiler-generated insertion of source code into a source program at 208, and conversion of inferred symbols to real symbols at 212. Compiler-generated code may represent consumed code that includes, for example, definitions of previously undefined symbols (e.g., generation of method declarations, class declarations, etc.), such as interfaces, events, and constructs. Selecting another option may cause the software development tool to display the inferred symbol in the software development tool at 210, such as, but not limited to: completion list, call hierarchy, reference list, object browser, class view, find reference, and/or navigation tool. The compiler generated code may be displayed as "preview" code. In this case, a specific symbol may be temporarily created. The temporary concrete symbol may become permanent in response to a user action confirming the action. Alternatively, the temporary specific symbol may be discarded in response to a user action to abandon the code. It will be appreciated that when the terms "compiler" and "compiler-generated" are used above, the module used to create the inferred symbol from code usage can contribute to compiler-generated code, be incorporated into the compiler or invoked by the compiler (as described above with reference to FIG. 1 a), and so forth.

Examples of suitable computing environments

In order to provide context for various aspects of the subject matter disclosed herein, FIG. 3 and the following discussion are intended to provide a brief, general description of a suitable computing environment 510 in which embodiments may be implemented. While the subject matter disclosed herein is described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other computing devices, those skilled in the art will recognize that portions of the subject matter disclosed herein also can be implemented in combination with other program modules and/or combinations of hardware and software. Generally, program modules include routines, programs, objects, physical artifacts, data structures, etc. that perform particular tasks or implement particular data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. The computing environment 510 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the subject matter disclosed herein.

With reference to FIG. 3, a computing device in the form of a computer 512 for creating inferred symbols from code usage is depicted. The computer 512 may include a processing unit 514, a system memory 516, and a system bus 518. The processing unit 514 can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 514. The system memory 516 may include volatile memory 520 and non-volatile memory 522. Non-volatile memory 522 may include Read Only Memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), or flash memory. Volatile memory 520 can include Random Access Memory (RAM), which can act as external cache memory. The system bus 518 couples system physical artifacts including the system memory 516 to the processing unit 514. The system bus 518 may be any of several types of bus structures including a memory bus, memory controller, peripheral bus, external bus, or local bus and may use any of a variety of available bus architectures.

Computer 512 typically includes a variety of computer readable media such as volatile and nonvolatile media, removable and non-removable media. Computer storage media may be implemented by any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium which can be used to store the desired information and which can accessed by computer 512.

It will be appreciated that FIG. 3 describes software that can act as an intermediary between users and computer resources. The software may include an operating system 528, which can be stored on disk storage 524, and which can control and allocate resources of the computer system 512. Disk storage 524 may be a hard disk drive connected to the system bus 518 through a non-removable memory interface such as interface 526. System applications 530 take advantage of the management of resources by operating system 528 through program modules 532 and program data 534 stored either in system memory 516 or on disk storage 524. It is to be appreciated that a computer can be implemented with various operating systems or combinations of operating systems.

A user may enter commands or information into the computer 512 through input device(s) 536. Input devices 536 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, and the like. These and other input devices connect to the processing unit 514 through the system bus 518 via interface port(s) 538. Interface port(s) 538 may represent a serial port, a parallel port, a Universal Serial Bus (USB), or the like. The output device 540 may use the same type of port as the input device. Output adapter 542 is provided to illustrate that there are some output devices 540 like monitors, speakers, and printers that require special adapters. Output adapters 542 include, but are not limited to, video and sound cards that provide a connection between the output device 540 and the system bus 518. Other devices and/or devices or systems, such as remote computer 544, may provide both input and output capabilities.

The computer 512 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 544. The remote computer 544 can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 512, although only a memory storage device 546 has been illustrated in fig. 4. Remote computer(s) 544 may be logically connected via a communication connection 550. Network interface 548 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN), but may also include other networks. Communication connection(s) 550 refers to the hardware/software employed to connect the network interface 548 to the bus 518. Connection 550 may be internal or external to computer 512 and include internal and external technologies such as modems (telephone, cable, DSL and wireless) and ISDN adapters, ethernet cards and so on.

It will be appreciated that the network connections shown are examples only, and other means of establishing a communications link between the computers may be used. One of ordinary skill in the art can appreciate that a computer 512 or other client device can be deployed as part of a computer network. In this regard, the subject matter disclosed herein relates to any computer system having any number of memory or storage units and any number of applications and processes occurring across any number of storage units or volumes. Aspects of the subject matter disclosed herein may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. Aspects of the subject matter disclosed herein may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities.

FIG. 4 illustrates an Integrated Development Environment (IDE) 600 and a common language runtime environment 602. The IDE 600 may allow a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug, or build programs, assemblies of programs, websites, web applications, and web services in a computer system. The software program may include source code (component 610) created in one or more source code languages (e.g., Visual basic, Visual J #, C + +, C #, J #, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk, etc.). The IDE 600 may provide a native code development environment, or may provide managed code development running on a virtual machine, or may provide a combination thereof. The IDE 600 may provide a managed code development environment using the NET framework.

An intermediate language component 650 may be created from the source code component 610 and the native code component 611 using a language specific source compiler 620, and the native code component 611 (e.g., machine executable instructions) may be created from the intermediate language component 650 using an intermediate language compiler 660 (e.g., a just-in-time (JIT) compiler) when executing the application. That is, when an IL application is executed, it is compiled while being executed into the appropriate machine language for the platform on which it is being executed, thereby enabling code to be portable across several platforms. Alternatively, in other embodiments, the program may be compiled into a native code machine language (not shown) suitable for its target platform.

A user may create and/or edit source code components via the user interface 640 and source code editor 651 in the IDE 600 according to known software programming techniques and the specific logical and syntactic rules associated with a particular source language. Thereafter, the source code component 610 can be compiled via a source compiler 620, whereby an intermediate language representation of the program, such as assembly 630, can be created. The assembly 630 can include an intermediate language component 650 and metadata 642.

The application design may be able to be verified before deployment.

The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus disclosed herein, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing aspects of the subject matter disclosed herein. In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may utilize the creation and/or implementation of domain-specific programming models aspects, e.g., through the use of a data processing API or the like, may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

While the subject matter disclosed herein has been described in connection with the appended drawings, it is to be understood that modifications may be made to perform the same function in a different manner.

Claims (15)

1. A system for creating inferred symbols from code usage, comprising:

a processor and a memory, the memory including modules configured to cause the processor to:

during program development:

creating a data structure comprising at least one inferred symbol generated by the module;

creating the at least one inferred symbol based on consuming code present in source code entered into a source code editor during the program development, the at least one inferred symbol representing code consumed by the consuming code, wherein consumed code is not present in the source code; and

converting the at least one inferred symbol to a real symbol based on receiving user input indicating to perform the conversion.

2. The system of claim 1, the at least one inferred symbol is created in a test-driven development environment or in a dynamic programming environment based on applying a set of rules to an undefined symbol.

3. The system of claim 1, wherein the data structure is a syntax tree, a semantic tree, or a symbol table.

4. The system of claim 1, wherein converting the at least one inferred symbol to a real symbol triggers an automatic, compiler-generated addition of source code defining the at least one inferred symbol, wherein the source code defining the at least one inferred symbol is added to the source code in the source code editor.

5. The system of claim 2, the software development tool in the dynamic programming environment displays developer help information associated with the at least one inferred symbol during program development in response to a user selection of an option to display information associated with the at least one inferred symbol.

6. A method for creating inferred symbols from code usage, comprising:

creating a data structure representing real symbols of source code, the data structure generated by a background compiler in a programming environment during interactive program development, wherein a module executing on a software development computer adds at least one inferred symbol to the data structure during the interactive program development, wherein the at least one inferred symbol is based on source code input into a source code editor, wherein the at least one inferred symbol is inferred from the source code based on use of undefined symbols in the source code; and

during the interactive program development, the at least one inferred symbol is converted to a real symbol based on receiving user input indicating to perform the conversion.

7. The method of claim 6, wherein the data structure is a syntax tree, a semantic tree, or a symbol table.

8. The method of claim 6, further comprising:

displaying information associated with the at least one inferred symbol in a software development tool in a programming environment in response to activation of an option in the programming environment, wherein the programming environment comprises a test-driven development environment or a dynamic programming development environment.

9. The method of claim 6,

compiler generated code is added to the source code defining the undefined symbol.

10. The method of claim 6, wherein converting the at least one inferred symbol to a real symbol triggers an automatic, compiler-generated addition of source code defining the at least one inferred symbol, wherein the source code defining the at least one inferred symbol is added to the source code in the source code editor.

11. A method for creating inferred symbols from code usage, comprising:

during program development, creating a data structure representing source code, the data structure generated by a background compiler, wherein at least one inferred symbol is added to the data structure based on source code input into a source code editor, wherein the at least one inferred symbol is inferred from the source code based on usage of a symbol without prior definition of the symbol; and

during the program development, the at least one inferred symbol is converted to a real symbol in response to receiving an indication from a user to convert the at least one inferred symbol to a real symbol.

12. The method of claim 11, further comprising:

creating the at least one inferred symbol based on applying a set of rules to the undefined symbol.

13. The method of claim 11, further comprising:

automatically adding compiler-generated code defining the at least one inferred symbol to the source code based on the at least one inferred symbol.

14. The method of claim 11, further comprising:

in response to activation of an option in the programming environment, information associated with the at least one inferred symbol is displayed in the software development tool.

15. The method of claim 11, further comprising:

creating a data structure comprising a semantic or syntax tree, the semantic or syntax tree comprising at least one inferred node; or creating a data structure comprising a symbol table comprising at least one inferred symbol.