Graph-Based Type Model for Linear Response Time

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In statically typed programming languages, global type inference can lead to computationally expensive operations in interactive development environments, as determining the type of a code element requires knowledge of all other code elements, resulting in quadratic computational costs and inefficiencies.

Innovation Solution

Modeling the type environment as a mathematical graph where nodes represent code elements and edges represent relationships, allowing for incremental type checking by storing and updating type information in a graph structure, which can delay computation until requested, reducing the computational burden.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If global type inference is used to determine the type of a code element, then type accuracy is improved, but computational cost increases quadratically with the number of declarations

Engineering Contradiction:
Improvetype accuracyVSAvoidcomputational cost
Core Design Contradiction:
Measurement precisionVSPower

Solution Approach 1:

The patent segments the global type inference problem into local type checking operations. Instead of computing types for all code elements simultaneously across the entire program, the system divides type checking into smaller, localized units that can be processed independently. This segmentation reduces the computational complexity from quadratic to linear by allowing type inference to proceed in discrete, manageable steps rather than requiring global analysis of all declarations at once.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary action by pre-computing and caching type information for code elements during initial parsing and analysis phases. Type data is collected and stored in advance during compilation or initial loading, so that subsequent type checking operations can reuse this pre-computed information without performing redundant computations. This preliminary preparation reduces the computational burden during interactive editing and type checking operations.

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If type checking is performed after every source code change to maintain current type understanding, then type information accuracy is improved, but response time deteriorates

Engineering Contradiction:
Improvetype information accuracyVSAvoidresponse time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent applies local quality by performing type checking only on the specific code elements and regions that are affected by source code changes, rather than re-checking the entire program. When a modification occurs, the system identifies and processes only the local type checking operations relevant to that change, leaving unaffected regions unchanged. This localized approach maintains type information accuracy for modified areas while avoiding unnecessary computational overhead elsewhere, thus improving response time.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements partial action by performing type checking selectively rather than comprehensively after every source code change. The system determines the minimal necessary scope of type checking required to maintain accuracy, checking only those code elements whose types may have been affected by the modification. This partial checking approach suffices to maintain current type understanding while significantly reducing the time cost compared to full program-wide type checking.

Inventive Principle:
Principle #16Partial or excessive action

3Productivity

If incremental type checking is implemented to reduce computational cost, then productivity is improved, but type checking completeness may be compromised

Engineering Contradiction:
Improvetype checking efficiencyVSAvoidtype checking completeness
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent implements feedback mechanisms to ensure type checking completeness in incremental processing. The system continuously monitors type relationships and propagates type information changes through the codebase, using feedback loops to verify that all affected type checks have been performed. This feedback ensures that even though only local regions are checked incrementally, the cumulative effect maintains complete and consistent type checking across the entire program, preserving reliability while improving productivity.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent maintains continuity of useful action by implementing incremental type checking that continuously updates type information as source code changes occur, rather than performing discrete batch processing. The type checking process runs continuously in the background, processing changes as they happen and maintaining up-to-date type information. This continuous incremental approach ensures completeness over time while maintaining high productivity, as the system never stops processing type information but does so in small, efficient increments.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS9696974B2Graph-based model for type systems
Publication Date: 2017.07.04 MICROSOFT TECHNOLOGY LICENSING LLC
  • US9696974B2 patent drawing
  • US9696974B2 patent drawing
  • US9696974B2 patent drawing

AI summary

The type environment of a program can be modeled as a graph. In the graph, a node can represent a code element including but not limited to a function, a class, an object, a variable, an expression, a script, a global, a primitive, a module, an interface, an enumerated list, an array, an alias for a type, a parameter, a property, a type, a method, a function expression, a call signature, an index signature, an object type, or a function type. An edge in the graph can represent a relationship between code elements. When the type of a code element changes, the graph can be changed to model the revised source code. Computations concerning effects of a type change are delayed until information concerning the affected code element is requested.