A data type derivation system for data programming

Abstract

The application discloses a data type derivation system for data programming, relates to the field of compiler and program analysis technology, and comprises a code intention topology construction module, an implicit contract constraint extraction module, a type evolution manifold coding module, a probability contract space deduction module, a compilation load sensing adjustment module, a contract anchor solidification module, an ambiguity contract arbitration module and a contract annotation intermediate representation generation module.

Description

Technical Field

[0001] This invention relates to the field of compiler and program analysis technology, and more specifically to a data type derivation system for data programming. Background Technology

[0002] In modern data programming, with the continuous expansion of software system scale and the increasing richness of language features, advanced features such as generic programming, polymorphic interfaces, and type guards in exception handling paths are widely used. While these features improve code expressiveness and reusability, they also introduce a large number of implicit type contracts—that is, semantic information in the code that is not explicitly declared but actually constrains type behavior. For example, an interface may be bound to different polymorphic implementations in different calling contexts, and its return type is constrained by covariance rules. The actual type of generic parameters often depends on the nested instantiation context. Type checking predicates in exception handling branches dynamically narrow the possible types of variables at runtime.

[0003] Existing static type inference techniques primarily rely on explicit type annotations and local syntactic structures for inference, lacking effective capabilities to capture and model the aforementioned implicit contracts. Specifically, existing techniques suffer from the following prominent problems: when the codebase is large and the inter-module call relationships are complex, implicit contracts often form chain dependencies across multiple functional units; traditional type inference systems typically perform inference on the entire codebase at a single, fixed granularity, failing to adaptively adjust the computational granularity based on the coupling density of functional units and the connectivity of the inference subgraph in the current compilation session, and also lacking a quantitative evaluation of the confidence level of the inference results. This mechanism leads to the derivation process being prone to timeouts or forced truncation due to constraint explosion in highly coupled regions, resulting in incomplete type information. In contrast, in low-coupling, highly deterministic regions, the system may ignore local details due to coarse granularity, causing avoidable derivation ambiguity. More importantly, when multiple candidate types with similar probabilities appear in the derivation results, existing technologies can only arbitrate based on local syntactic contexts and cannot combine cross-module collaborative topology to perform global consistency checks. This frequently results in suboptimal type decisions and propagates errors downstream, ultimately making it difficult for developers to locate the true root cause of type errors.

[0004] Therefore, there is an urgent need for an intelligent data type derivation system that can integrate program intent topology analysis, probabilistic contract reasoning, and compiler load awareness adjustment to solve the technical problems of rigid implicit contract derivation granularity, unquantifiable confidence, and lack of global perspective in ambiguity arbitration. Summary of the Invention

[0005] To address the aforementioned technical problems, a data type derivation system for data programming is provided, and this technical solution resolves the problems described above.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A data type derivation system for data programming, comprising:

[0008] The code intent topology construction module performs cross-module semantic parsing and call contract analysis on the source code input stream to generate a program intent topology network.

[0009] The implicit contract constraint extraction module traverses the program intent topology network to extract interface polymorphic contracts, generic parameter binding contexts, and type guard assertions within exception handling paths.

[0010] The type evolution manifold encoding module constructs a dynamic type evolution manifold based on interface polymorphic contracts, generic parameter binding contexts, and type guard assertions.

[0011] The probabilistic contract space deduction module inputs the dynamic type evolution manifold into the Markov logic network and calculates the posterior contract distribution and logical confidence through weighted first-order logic inference.

[0012] Compile the load-aware adjustment module and generate a contract derivation granularity control factor based on the functional unit coupling density and the scale of the connected components of the contract derivation subgraph.

[0013] The contract anchor solidification module selects the contract with the highest joint probability as the anchor contract and generates a contract solidification certificate when the logical confidence level meets the contract derivation granularity control factor.

[0014] The ambiguous contract arbitration module performs a global contract consistency check and generates a contract arbitration decision when there are multiple candidate contracts with a joint probability difference lower than a preset fuzzy threshold.

[0015] The contract annotation intermediate representation generation module generates and outputs a contract annotation intermediate representation carrying contract confidence metadata based on the contract solidification certificate and the contract arbitration decision.

[0016] Preferably, the program intent topology network is traversed to extract type guard assertions within interface polymorphic contracts, generic parameter binding contexts, and exception handling paths, including:

[0017] Locate the interaction edges of functional units in the topology network of the program intent, extract the polymorphic implementation candidate set of the interface nodes associated with the interaction edge and the covariance constraints of their return types, as the interface polymorphic contract;

[0018] The program scans generic instantiation nodes in the intent topology network, extracts the actual binding expressions of type parameters and the upper and lower bound constraints of formal parameters, and constructs a type parameter binding path tree as the generic parameter binding context.

[0019] By tracing the anomaly capture nodes in the program intent topology network, extracting the type checking predicates and their negations involved in the capture expressions, and combining them with the merging logic of the anomaly propagation convergence point, type guard assertions are generated.

[0020] Preferably, a dynamic type evolution manifold is constructed based on interface polymorphic contracts, generic parameter binding contexts, and type guard assertions, including:

[0021] Partial-order set encoding is performed on the subtype compatibility relationship in the interface polymorphic contract to generate type hierarchy relationship feature components;

[0022] Recursive expansion counting is performed on the nesting depth in the generic parameter binding context, and graph embedding encoding is performed on the type parameter binding path tree to extract the dimensionality-reduced generic context feature components.

[0023] The number of exclusive type check predicates and the constraint strength of each predicate in the statistical type guard assertion are used to calculate the type guard deterministic feature components.

[0024] Perform manifold alignment transformation on the type hierarchy relation feature components, generic context feature components, and type guard deterministic feature components, and splice them to generate a dynamic type evolution manifold.

[0025] Preferably, when the logical confidence level satisfies the contract derivation granularity control factor, the contract with the highest joint probability is selected as the anchor contract and a contract solidification certificate is generated, including:

[0026] Establish a temporary storage area for contract decisions for each functional unit;

[0027] When the logical confidence level is greater than the contract derivation granularity control factor, the contract solidification priority is determined based on the ratio of the logical confidence level to the contract derivation granularity control factor.

[0028] Extract the candidate contract with the highest joint probability from the posterior contract distribution, bind the candidate contract to the symbol table slot of the functional unit, and generate a contract solidification record;

[0029] Write the contract solidification record into the contract decision temporary storage area, and attach a derivation version number and constraint source traceability chain to the contract solidification record as a contract solidification certificate.

[0030] Preferably, when there are multiple candidate contracts with joint probability differences lower than a preset fuzzy threshold, a global contract consistency check is performed and a contract arbitration decision is generated, including:

[0031] Extract the cross-module cooperative neighbor set of the functional unit in the program intent topology network. The cooperative neighbor set contains all callers, callees and closure capture variables that directly or indirectly call the functional unit.

[0032] Calculate the contract compatibility score matrix between the fixed contracts of each node in the cooperative neighbor set and the candidate contracts in the posterior contract distribution;

[0033] The candidate contract with the highest score in the contract compatibility score matrix is ​​selected as the preferred arbitration contract.

[0034] Perform cross-module consistency checks on the arbitration preferred contract, and check whether there are contract constraints in the cooperative neighbor set that violate the subtype relationship of the arbitration preferred contract;

[0035] If there are no contractual constraints that violate the subtype relationship, the preferred arbitration contract will be used as the final derived contract and a contract arbitration decision will be generated; if there are contractual constraints that violate the subtype relationship, the preferred arbitration contract will be marked as a contract to be negotiated and a cross-module contract negotiation protocol will be triggered.

[0036] Preferably, after generating the intermediate representation of the contract annotation carrying contract confidence metadata based on the contract solidification certificate and the contract arbitration decision, it further includes:

[0037] Based on the contract confidence metadata in the intermediate representation of the contract annotation, a directed acyclic graph of global contract propagation influence is constructed. The directed acyclic graph contains the contract dependency edges of all functional units and their confidence decay coefficients.

[0038] Detect whether there are propagation paths in the directed acyclic graph where the cumulative confidence decays beyond a preset confidence lower limit;

[0039] When a propagation path is detected where the cumulative confidence decay exceeds the preset confidence lower limit, the sequence of functional units constituting the propagation path and the corresponding reasons for the relaxation of contract constraints are extracted.

[0040] The functional unit sequence and the reasons for the relaxation of contract constraints are encapsulated into a contract deduction confidence warning report, which is then output to the integrated development environment to prompt users to supplement explicit contract annotations.

[0041] Preferably, cross-module semantic parsing and call contract analysis are performed on the source code input stream to generate a program intent topology network, including:

[0042] Establish an incremental synchronization channel with the version control system;

[0043] When the version control system detects a code change commit event, it captures differentiated source code input stream fragments through the incremental synchronization channel.

[0044] Incremental lexical analysis is performed on the source code input stream fragments, only re-parses the affected lexical unit sequences, and retains the cached lexical results of the unchanged parts;

[0045] Based on a pre-defined program database model, cross-module symbolic link parsing is performed on the incremental lexical analysis results to construct a program intent topology network, and a change timestamp and impact range label are attached to each hyperedge.

[0046] Preferably, after writing the contract solidification record to the contract decision temporary storage area, the method further includes:

[0047] Extract evidence of actual contract usage from functional units during subsequent compilation or runtime;

[0048] Calculate the semantic offset distance between the actual contractual evidence and the anchored contract in the contractual record;

[0049] The semantic offset distance is compared with a preset contract stability threshold;

[0050] When the semantic offset distance exceeds the contract stability threshold, the constraint source tracing chain of the functional unit and the offset reason are packaged into a contract deduction evolution sample and injected into the local contract knowledge base to drive the prior distribution of the Markov logic network to be updated adaptively.

[0051] Preferably, the dynamic type evolution manifold is input into the Markov logic network, and the posterior contract distribution and logical confidence are calculated through weighted first-order logical inference, including:

[0052] A contract hierarchy prior graph is constructed in the Markov logic network. The contract hierarchy prior graph includes the inheritance relationship of the language's built-in contract system and the extension relationship of user-defined contracts.

[0053] Using dynamic type evolution manifolds as observational evidence, weighted first-order logical reasoning is performed on the contract-level a priori graph;

[0054] Iteratively update the variational posterior parameters of each functional unit until convergence;

[0055] Substitute the converged variational posterior parameters into the preset logical confidence calculation formula to obtain the logical confidence corresponding to each functional unit.

[0056] Contract candidates with a logical confidence level higher than a preset acceptable lower limit are extracted and used to form a posterior contract distribution.

[0057] Preferably, after encapsulating the functional unit sequence and the reasons for the relaxation of contract constraints into a contract derivation confidence warning report, it also includes:

[0058] For the functional unit sequence in the contract derivation confidence warning report, extract the contract change frequency and cross-module dependency strength of each functional unit in the historical compilation cycle;

[0059] Input the contract change frequency and cross-module dependency strength into the pre-built contract vulnerability assessment model to calculate the contract vulnerability index of each functional unit.

[0060] When the contract vulnerability index exceeds the preset vulnerability threshold, the corresponding functional unit will be marked as a high-vulnerability node.

[0061] For highly vulnerable nodes, contract hardening suggestions are automatically generated. These suggestions include the insertion position of explicit type annotations, contract constraint strengthening schemes, and cross-module interface isolation strategies.

[0062] Contract hardening recommendations are presented in the form of a visual graph in the integrated development environment, allowing users to apply the recommendations with one click to eliminate weaknesses in contract derivation.

[0063] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0064] 1. By constructing a program intent topology network and extracting interface polymorphic contracts, generic parameter binding contexts, and type guard assertions, implicit semantics scattered in cross-module call chains, generic instantiation paths, and exception handling branches are explicitly transformed into inferable structured constraints, improving the coverage and accuracy of type inference in complex data programming scenarios. A compilation load-aware adjustment mechanism is introduced, which automatically generates granularity control factors based on the coupling density of functional units and the scale of connected components in the contract inference subgraph. This enables the system to adaptively reduce the inference granularity in highly coupled regions to avoid performance bottlenecks, while improving inference accuracy in low-coupling, high-confidence regions, thus optimizing overall compilation efficiency while ensuring type safety.

[0065] 2. For situations where multiple high-probability candidates exist in the posterior contract distribution, contract compatibility scoring and global consistency verification are performed through cross-module collaborative neighbor sets. Combined with weighted first-order inference using Markov logic networks, this ensures that type decisions are both logically rigorous and probabilistically reasonable, avoiding suboptimal choices based solely on local information. An intermediate representation of the contract annotation carrying confidence metadata is generated, and confidence decay paths are detected through global contract propagation in a directed acyclic graph, outputting a warning report containing the reasons for relaxation. Furthermore, contract vulnerability is assessed by combining historical change frequency and dependency strength, automatically generating visual reinforcement suggestions to help developers accurately identify and fix weaknesses in type inference. Incremental parsing is achieved through integration with version control systems, and a traceability chain is added to the contract solidification record. When the actual contract usage evidence from subsequent compilation or runtime feedback deviates semantically from the anchored contract, the deviation is automatically implied as a sample and injected into the local knowledge base, driving adaptive updates to the prior distribution, enabling the system to continuously learn as the project evolves. Attached Figure Description

[0066] Figure 1 This is a system architecture diagram of the present invention. Detailed Implementation

[0067] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0068] Example 1: Refer to Figure 1 As shown, a data type derivation system for data programming includes:

[0069] The code intent topology construction module performs cross-module semantic parsing and call contract analysis on the source code input stream to generate a program intent topology network. This module receives source code input streams from an integrated development environment or a compiler frontend, and uses a pre-built language grammar parser to complete lexical analysis and syntax tree construction. Based on this, it identifies semantic relationships such as function calls, interface implementations, and generic instantiation across the boundaries of individual files or modules. Each functional unit is abstracted as a topology node, and functional units include functions, classes, or closures. The call, inheritance, and data dependency relationships between units are abstracted as hyperedges, ultimately generating a program intent topology network that reflects the global semantic structure of the program. The program intent topology network is a structured data representation stored in the form of a directed hypergraph, containing all functional units and their cross-module semantic relationships.

[0070] The implicit contract constraint extraction module traverses the program intent topology network to extract interface polymorphic contracts, generic parameter binding contexts, and type guard assertions within exception handling paths. This module performs a depth-first traversal along the hyperedges and nodes of the program intent topology network, extracting the polymorphic implementation candidate set and covariance constraints of the return type for each interaction edge. For each generic instantiation node, it extracts the actual type parameter binding expression and the upper and lower bounds of the formal parameters. For each exception handling node, it extracts the type check predicate and its negation form, and generates type guard assertions by combining the merging logic of exception propagation convergence points. Implicit contract constraints refer to the set of semantic information about the type behavior of actual constraint variables or expressions that are not declared through explicit type annotations.

[0071] The type evolution manifold encoding module constructs a dynamic type evolution manifold based on interface polymorphic contracts, generic parameter binding contexts, and type guard assertions. This module performs partial order set encoding on subtype compatibility relationships in interface polymorphic contracts to generate type hierarchy relationship feature components; it performs recursive expansion counting on the nesting depth in generic parameter binding contexts and graph embedding encoding on type parameter binding path trees to extract dimensionality-reduced generic context feature components; it statistically analyzes the number of exclusive type check predicates and the constraint strength of each predicate in type guard assertions to calculate type guard deterministic feature components; finally, it performs manifold alignment transformation on the above three types of feature components and concatenates them to generate a dynamic type evolution manifold. The dynamic type evolution manifold is a vectorized representation of discrete implicit contract constraints mapped to a continuous low-dimensional manifold space, used for subsequent probabilistic inference.

[0072] The probabilistic contract space deduction module inputs a dynamic type evolution manifold into a Markov logic network and calculates the posterior contract distribution and logical confidence level through weighted first-order logical inference. This module constructs a hierarchical prior graph of contracts within the Markov logic network, including inheritance relationships of the language's built-in contract system and user-defined contract extension relationships. The dynamic type evolution manifold is injected into this prior graph as observational evidence, and weighted first-order logical inference is performed, iteratively updating the variational posterior parameters of each functional unit until convergence. The converged variational posterior parameters are substituted into a preset logical confidence level calculation formula to obtain the logical confidence level corresponding to each functional unit. Contract candidates with logical confidence levels higher than a preset acceptable lower limit are extracted to form the posterior contract distribution. The posterior contract distribution refers to the set of contract types and their corresponding probabilities that each functional unit may bind to given observational evidence.

[0073] The compiler load-aware adjustment module generates a contract derivation granularity control factor based on the coupling density of functional units and the scale of connected components in the contract derivation subgraph. This module calculates the sum of the in-degree and out-degree of each functional unit in the current compilation session as a coupling density index and calculates the number of connected component nodes in the current contract subgraph to be derived as a scale index. The two are weighted and fused and then normalized to generate the contract derivation granularity control factor. The contract derivation granularity control factor is a scalar between 0 and 1, used to dynamically adjust the trigger threshold of the subsequent contract anchor point solidification module. The larger the value, the more relaxed the derivation precision is allowed in exchange for compilation performance.

[0074] The contract anchor point solidification module selects the contract with the highest joint probability as the anchor contract and generates a contract solidification certificate when the logical confidence level meets the contract derivation granularity control factor. This module establishes a contract decision temporary storage area for each functional unit. When the logical confidence level of a functional unit is greater than the contract derivation granularity control factor, the contract solidification priority is determined based on the ratio of the two. The module extracts the candidate contract with the highest joint probability from the posterior contract distribution and binds it to the symbol table slot of the functional unit to generate a contract solidification record. This record is written to the temporary storage area and appended with the derivation version number and constraint source traceability chain as a contract solidification certificate. The contract solidification certificate is an immutable data structure that records the contract of a determined type and its derivation source traceability information.

[0075] The ambiguous contract arbitration module performs a global contract consistency check and generates a contract arbitration decision when multiple candidate contracts have a joint probability difference lower than a preset fuzzy threshold. When two or more candidate contracts in the posterior contract distribution have a joint probability difference lower than a preset fuzzy threshold, the module extracts the cross-module collaborative neighbor set of the target functional unit in the program intent topology network. The cross-module collaborative neighbor set includes direct callers, indirect callers, callees, and closure capture variables. It calculates the contract compatibility score matrix between the fixed contracts of each node in the neighbor set and each candidate contract. The candidate contract with the highest score is selected as the preferred arbitration contract, and a cross-module consistency check is performed on it. If the check passes, a contract arbitration decision is generated; otherwise, it is marked as a contract to be negotiated and a cross-module contract negotiation protocol is triggered. The contract arbitration decision is the final type contract decision record determined after global consistency verification in ambiguous scenarios.

[0076] The contract annotation intermediate representation generation module generates and outputs a contract annotation intermediate representation carrying contract confidence metadata based on the contract solidification certificate and contract arbitration decision. This module injects the type contract information from the contract solidification certificate and contract arbitration decision into the corresponding symbol nodes of the compiler intermediate representation, and adds metadata fields such as logical confidence, derivation version number, and constraint source tracing chain to each contract annotation, generating a contract annotation intermediate representation that can be consumed by subsequent compilation stages or IDE plugins. The contract annotation intermediate representation is an enhanced intermediate representation format that extends the type contract confidence metadata on the basis of the standard compiler IR.

[0077] Through the above technical solutions, the system transforms implicit type contracts that are difficult for traditional compilers to handle into inferable structured constraints, and achieves a dynamic balance between derivation accuracy and performance through probabilistic graphical models and compiler load awareness mechanisms. At the same time, it introduces cross-module global arbitration and confidence propagation tracing, so that the type derivation results have both logical rigor and engineering practicality, and alleviate the problems of type derivation blind spots, ambiguity misjudgment and difficulty in error propagation and location in complex data programming scenarios.

[0078] In some embodiments, the implicit contract constraint extraction module traverses the program intent topology network to extract interface polymorphic contracts, generic parameter binding contexts, and type guard assertions within exception handling paths, including the following steps:

[0079] S201. Locate the functional unit interaction edges in the program intent topology network, extract the polymorphic implementation candidate set of the interface nodes associated with the interaction edge and their covariance constraints of return types, as the interface polymorphic contract; traverse all hyperedges of type call or implementation in the program intent topology network, for each interface node connected by the hyperedge, query all polymorphic implementation classes or functions registered in the symbol table, collect their return type declarations and covariance relationships relative to the interface declaration, and encapsulate them into an interface polymorphic contract structure; the covariance relationship includes subtype return or generic specialization; the interface polymorphic contract describes the constraint set of all possible runtime implementations of an interface at a specific call point and their type compatibility relationships.

[0080] S202. Scan the generic instantiation nodes in the intent topology network of the program, extract the actual binding expressions of type parameters and the upper and lower bound constraints of formal parameters, and construct a type parameter binding path tree as the generic parameter binding context; for each instantiation node of a generic function or generic class, extract the actual type parameter expression passed at the call site and match it with the upper and lower bounds of the formal parameters at the generic definition; the upper and lower bounds of the formal parameters include the extends constraint or the super constraint; trace upwards along the nested instantiation chain to construct a type parameter binding path tree with the current instantiation node as the root and the generic parameter binding relationships at each level as the edges; the generic parameter binding context completely records the full-link constraint transmission path of generic type parameters from definition to instantiation;

[0081] S203. Tracing the exception capture nodes in the program intent topology network, extracting the type checking predicates and their negations from the capture expressions, and combining them with the merging logic of the exception propagation convergence point to generate type guard assertions; for each catch node or try-with-resources node, parsing the instanceof operation, type conversion, or custom type checking function call in its capture condition, and extracting the positive and negative type predicates; tracing upwards along the exception propagation path to the nearest convergence point, which includes finally blocks or outer catch blocks; combining the type predicates on multiple propagation paths according to the merging logic to generate type guard assertions; the merging logic includes intersection operations or union operations; a type guard assertion is a logical predicate expression that can dynamically narrow or expand the set of possible variable types in the exception handling path;

[0082] Through the above steps, the system systematically extracts three types of key implicit contracts from the program intent topology network, and transforms the type constraints scattered in the interface implementation, generic instantiation and exception handling paths into structured data, providing input evidence for subsequent manifold coding and probabilistic reasoning.

[0083] In some embodiments, the type evolution manifold encoding module constructs a dynamic type evolution manifold based on interface polymorphic contracts, generic parameter binding contexts, and type guard assertions, including the following steps:

[0084] S301. Encode the subtype compatibility relationships in the interface polymorphic contract using a partial order set to generate type hierarchy relationship feature components; construct a partial order set for all types involved in the interface polymorphic contract according to the subtype relationships, assign a rank value and a coverage relationship vector in the partial order set to each type, and concatenate the rank value and coverage relationship vector to form a fixed-dimensional type hierarchy relationship feature component; the type hierarchy relationship feature component expresses the relative position and compatibility range of the type in the inheritance system in the form of a numerical vector.

[0085] S302. Perform recursive expansion counting on the nesting depth in the generic parameter binding context, and perform graph embedding encoding on the type parameter binding path tree to extract the dimensionality-reduced generic context feature components; count the depth and breadth of the type parameter binding path tree as nesting depth indicators; use a pre-trained graph neural network to perform node embedding on the type parameter binding path tree, mapping the tree structure into a fixed-dimensional dense vector, and then perform principal component analysis to reduce the dimensionality to obtain the generic context feature components; the generic context feature components express the generic parameter binding complexity and context dependency pattern in the form of low-dimensional dense vectors.

[0086] S303. Calculate the type guard deterministic feature components by counting the number of exclusive type check predicates and the constraint strength of each predicate in the statistical type guard assertion; for each type guard assertion, count the number of mutually exclusive type check predicates and assign a constraint strength weight to each predicate according to the width of its constrained type range, with a higher weight for narrower ranges; normalize the sum of the number of predicates and the weighted constraint strength as the type guard deterministic feature component; the type guard deterministic feature component expresses the degree of type narrowing certainty in the abnormal path in scalar form;

[0087] S304. Perform manifold alignment transformation on the type hierarchy relation feature components, generic context feature components, and type guard deterministic feature components, and concatenate them to generate a dynamic type evolution manifold; use canonical correlation analysis or manifold alignment algorithm to map the three types of heterogeneous feature components to the same low-dimensional manifold space, so that contract constraints with similar semantics are close in distance in the manifold space; concatenate the aligned feature vectors according to the channel dimension to generate a dynamic type evolution manifold; the dynamic type evolution manifold uniformly encodes multi-source heterogeneous implicit contract constraints into a continuous low-dimensional space, which is convenient for subsequent probabilistic model inference;

[0088] Through the above steps, the system transforms discrete, heterogeneous implicit contract constraints into continuous, isomorphic manifold representations, preserving the semantic structure of the original constraints while adapting to the numerical reasoning interface of Markov logic networks, thus achieving the connection between symbolic reasoning and probabilistic reasoning.

[0089] In some embodiments, when the logical confidence level meets the contract derivation granularity control factor, the contract anchor point solidification module selects the contract with the highest joint probability as the anchor contract and generates a contract solidification certificate, including the following steps:

[0090] S401. Establish a contract decision temporary storage area for each functional unit; allocate an independent contract decision temporary storage area in memory for each functional unit to be deduced. This temporary storage area is stored in the form of a hash table, with the key being the unique identifier of the functional unit and the value being a list of contract solidification records; the contract decision temporary storage area is used to cache the contract results that have been deduced in the current compilation session.

[0091] S402. When the logical confidence level is greater than the contract derivation granularity control factor, the contract solidification priority is determined based on the ratio of the logical confidence level to the contract derivation granularity control factor. When the logical confidence level of a functional unit exceeds the current contract derivation granularity control factor, the ratio of the two is calculated as the solidification priority score. The higher the ratio, the more reliable the derivation result of the unit is, and it should be solidified first to avoid being covered by subsequent low-confidence results. The contract solidification priority determines the processing order of multiple contracts to be solidified.

[0092] S403. Extract the candidate contract with the highest joint probability from the posterior contract distribution, bind the candidate contract to the symbol table slot of the functional unit, and generate a contract solidification record; select the contract candidate with the highest joint probability from the posterior contract distribution, bind its type information to the corresponding slot of the functional unit in the compiler symbol table, record the binding timestamp, contract source and joint probability value, and encapsulate it into a contract solidification record; the contract solidification record is an immutable data object that records the contract of a determined type and its binding context;

[0093] S404. Write the contract solidification record into the contract decision temporary storage area, and attach a derivation version number and constraint source tracing chain to the contract solidification record as a contract solidification certificate; insert the contract solidification record into the temporary storage area list of the corresponding functional unit, and attach the version number of the current derivation engine and the complete reasoning path from the observed evidence to the contract. The reasoning path is the constraint source tracing chain, which together constitutes the contract solidification certificate; the contract solidification certificate has version management and source tracing capabilities and can be used in the subsequent compilation stage or IDE display.

[0094] Through the above steps, the system, while ensuring the reliability of the derivation, achieves controllability and auditability of the contract solidification process through priority scheduling and version traceability mechanisms, providing an anchor point for subsequent ambiguity arbitration and confidence propagation.

[0095] In some embodiments, when there are multiple candidate contracts with a joint probability difference lower than a preset fuzzy threshold, the ambiguous contract arbitration module performs a global contract consistency check and generates a contract arbitration decision, including the following steps:

[0096] S501. Extract the cross-module cooperative neighbor set of the functional unit in the program intent topology network; with the target functional unit as the center, perform a k-hop neighborhood search in the program intent topology network, where the value of k is configurable and the default is 2; collect all reachable caller nodes, callee nodes, and external variable nodes captured in the closure to form the cross-module cooperative neighbor set; the cross-module cooperative neighbor set is the set of all relevant functional units that have direct or indirect semantic interaction with the target functional unit;

[0097] S502. Calculate the contract compatibility score matrix between the fixed contracts of each node in the cooperative neighbor set and the candidate contracts in the posterior contract distribution; for each node with a fixed contract in the neighbor set, calculate the subtype compatibility, generic parameter matching degree, and abnormal contract consistency between its contract type and each candidate contract in the posterior contract distribution of the target unit, and sum them by weight to obtain the compatibility score; arrange all scores in matrix form; the contract compatibility score matrix quantitatively describes the degree of compatibility between each candidate contract of the target unit and the fixed contracts of its cooperative context;

[0098] S503. Select the candidate contract with the highest score in the contract compatibility score matrix as the preferred arbitration contract; sum or take the maximum value of the contract compatibility score matrix by row, and select the candidate contract with the highest comprehensive compatibility as the preferred arbitration contract; the preferred arbitration contract is the contract candidate that temporarily wins after local context compatibility evaluation in ambiguous scenarios.

[0099] S504. Perform cross-module consistency checks on the preferred arbitration contract, checking whether there are contract constraints in the cooperative neighbor set that violate the subtype relationship with the preferred arbitration contract; traverse all fixed contracts in the cooperative neighbor set, checking one by one whether they violate the language-defined subtype rules, generic boundary constraints, or abnormal contract compatibility with the preferred arbitration contract; if any violation is found, the check fails; cross-module consistency checks verify whether the preferred arbitration contract is compatible with the determined type constraints of the entire cooperative context;

[0100] S505. If there are no contractual constraints that violate the subtype relationship, the preferred arbitration contract will be used as the final derived contract and a contract arbitration decision will be generated. If there are contractual constraints that violate the subtype relationship, the preferred arbitration contract will be marked as a contract to be negotiated and a cross-module contract negotiation protocol will be triggered. If the verification passes, the preferred arbitration contract will be solidified as the final result and a contract arbitration decision containing the arbitration reasons and compatibility score will be generated. If the verification fails, the contract will be marked as a contract to be negotiated and a negotiation request will be sent to the relevant module, waiting for manual intervention or an automatic negotiation mechanism to resolve the issue. The contract arbitration decision is a final type contract record with complete decision-making basis generated after global consistency verification in ambiguous scenarios.

[0101] Through the above steps, when ambiguity arises in the probabilistic derivation, the system performs a global consistency check through cross-module collaborative topology to ensure that the final type decision remains type-safe throughout the entire call chain, reducing the risk of global type errors caused by local optima.

[0102] In some embodiments, after the contract annotation intermediate representation generation module generates a contract annotation intermediate representation carrying contract confidence metadata based on the contract solidification certificate and the contract arbitration decision, the method further includes the following steps:

[0103] S601. Based on the contract confidence metadata in the intermediate representation of the contract annotation, construct a directed acyclic graph of global contract propagation influence; using each functional unit in the intermediate representation of the contract annotation as a node and the constraint source traceability chain in the contract solidification certificate as an edge, construct a directed acyclic graph; for each edge, calculate the confidence decay coefficient based on the difference in logical confidence between the source node and the target node and the derivation hop count; the directed acyclic graph of global contract propagation influence depicts the propagation path and decay degree of type contract confidence in the program;

[0104] S602. Detect whether there are propagation paths in the directed acyclic graph where the cumulative confidence decay exceeds a preset confidence lower limit for the global contract propagation impact; for all paths from the source node to the leaf node in the directed acyclic graph, accumulate the confidence decay coefficient of each edge on the path; when the cumulative decay value exceeds the preset confidence lower limit, mark the path as a high-risk propagation path; cumulative confidence decay refers to the total loss of contract confidence after being passed down level by level along the derivation chain;

[0105] S603. When a propagation path is detected where the cumulative confidence decay exceeds a preset confidence lower limit, extract the sequence of functional units constituting the propagation path and the corresponding reasons for contract constraint slack; for each high-risk propagation path, extract the identifier sequence of all functional units on the path, and analyze the main reasons for confidence decay on each edge, encapsulating them as reasons for contract constraint slack; the main reasons include implicit contract missing, excessive generic nesting, or abnormal path merging; the reasons for contract constraint slack refer to the specific technical factors that cause the contract confidence to decrease during the propagation process;

[0106] S604. Encapsulate the functional unit sequence and its contract constraint slackness reasons into a contract deduction confidence warning report, and output it to the integrated development environment to prompt users to supplement explicit contract annotations; package the functional unit sequence, contract constraint slackness reasons, cumulative decay values, and suggested operations into a standard JSON format contract deduction confidence warning report, push it to the developer interface through the IDE plugin interface, highlight the relevant code locations, and provide a quick way to add explicit annotations; the contract deduction confidence warning report is an interactive diagnostic document for developers that includes problem location and repair suggestions;

[0107] Through the above steps, the system not only outputs the type derivation results, but also proactively identifies and warns of weak links in confidence propagation, transforming the derivation process into interpretable feedback, helping developers locate the root cause of type errors, and forming an improvement closed loop of derivation, warning, and reinforcement.

[0108] In some embodiments, the code intent topology construction module performs cross-module semantic parsing and call contract analysis on the source code input stream to generate a program intent topology network, including the following steps:

[0109] S701. Establish an incremental synchronization channel with the version control system; establish a real-time communication channel with the local or remote version control system through Git hooks or IDE file system listeners to capture code change events; the incremental synchronization channel can detect code file addition, deletion, and modification operations in real time.

[0110] S702. When the version control system detects a code change commit event, it captures differentiated source code input stream fragments through the incremental synchronization channel. When the version control system triggers a commit or save event, it obtains the diff information of the changed file through the incremental synchronization channel and extracts only the newly added or modified code fragments as source code input stream fragments. The source code input stream fragment is the smallest code unit containing only the changed content, not the entire file.

[0111] S703: Perform incremental lexical analysis on the source code input stream segment, only re-parse the affected lexical unit sequence, and retain the cached lexical results of the unchanged part; use the incremental lexical analyzer to perform lexical scanning on the changed segment, only regenerate the token stream for the lexical units in the affected region, and directly reuse the cached lexical results for the unchanged region; incremental lexical analysis only performs lexical scanning on the changed part and reuses the cache for the rest, which improves processing efficiency;

[0112] S704. Based on a pre-defined program database model, perform cross-module symbolic link parsing on the incremental lexical analysis results, construct a program intent topology network, and attach a change timestamp and impact range label to each hyperedge; link the incremental lexical analysis results with the existing symbol table in the program database, and update the affected topology nodes and hyperedges; attach a change timestamp and impact range label to each newly added or modified hyperedge, where the impact range label includes whether it only affects this module or propagates across modules; the program intent topology network supports incremental updates and has change tracking capabilities;

[0113] Through the above steps, the system avoids the performance overhead of performing a full parsing for every code change. By using incremental synchronization and cache reuse mechanisms, the program intent topology network can respond to code evolution, providing timeliness assurance for subsequent derivations.

[0114] In some embodiments, after the contract anchor point solidification module writes the contract solidification record into the contract decision temporary storage area, the following steps are also included:

[0115] S801. Extract evidence of actual contract usage from the functional unit during subsequent compilation or runtime. During subsequent compilation or runtime, collect the type information, method signature matching results, or runtime type check results actually used by the functional unit as evidence of actual contract usage. Subsequent compilation includes type checking or code generation, and runtime includes reflection calls or serialization. Evidence of actual contract usage is real type behavior data observed in actual use scenarios after derivation.

[0116] S802. Calculate the semantic offset distance between the actual contract usage evidence and the anchored contract in the contract solidification record; align the actual contract usage evidence and the anchored contract in the type hierarchy space, calculate the comprehensive deviation between the two in terms of subtype relationship, generic parameter matching degree and abnormal contract consistency, and quantify it as semantic offset distance; the semantic offset distance measures the degree of difference between the type semantics between the derivation result and the actual use.

[0117] S803. Compare the semantic offset distance with the preset contract stability threshold. The calculated semantic offset distance is compared with the preset contract stability threshold, which can be dynamically adjusted according to the project's historical data. The contract stability threshold is the critical value for determining whether the derivation result is stable.

[0118] S804. When the semantic offset distance exceeds the contract stability threshold, the constraint source tracing chain and offset reason of the functional unit are packaged into a contract deduction evolutionary sample and injected into the local contract knowledge base to drive the prior distribution of the Markov logic network to adaptively update. When the semantic offset distance exceeds the threshold, the constraint source tracing chain, semantic offset distance, offset reason, and actual contract usage evidence of the functional unit are encapsulated into a contract deduction evolutionary sample and stored in the local contract knowledge base. The prior weights of the Markov logic network are fine-tuned periodically using the evolutionary samples in the knowledge base so that the prior distribution gradually adapts to the actual type of use mode of the project. The contract deduction evolutionary sample is used to drive the adaptive learning of the probabilistic model.

[0119] Through the above steps, the system establishes a feedback loop from the derivation results to actual use, enabling the probabilistic contract space derivation module to continuously learn as the project evolves, improve the derivation accuracy, and overcome the limitation that static prior distribution cannot adapt to project-specific type patterns.

[0120] In some embodiments, the probabilistic contract space deduction module inputs a dynamic type evolution manifold into a Markov logic network and calculates the posterior contract distribution and logical confidence through weighted first-order logic inference, including the following steps:

[0121] S901. Construct a contract hierarchy prior graph in a Markov logic network; based on the programming language specification and project-defined contract annotations, construct a prior graph containing all types of contract nodes and their inheritance, extension, and compatibility relationships; assign an initial weight to each edge, the weight reflecting the frequency of the relationship in historical projects or the degree of enforceability in the language specification; the contract hierarchy prior graph encodes knowledge of the type contract architecture.

[0122] S902. Using the dynamic type evolution manifold as observational evidence, weighted first-order logic reasoning is performed on the contract-level prior graph; the eigenvectors in the dynamic type evolution manifold are used as observational evidence nodes of the Markov logic network, and evidence is bound to the corresponding nodes in the contract-level prior graph; reasoning is performed on the prior graph using weighted first-order logic formulas, which include subtype transitivity laws or generic covariance rules; weighted first-order logic reasoning is performed jointly inferred by combining logic rules and observational evidence within the framework of a probabilistic graphical model.

[0123] S903. Iteratively update the variational posterior parameters of each functional unit until convergence; using the mean-field variational inference algorithm, iteratively update the posterior distribution parameters of the contract variables of each functional unit until the change in the variational lower bound is less than the preset convergence threshold; the variational posterior parameters are the parameterized representation of the approximate posterior distribution, used to approximate the true posterior.

[0124] S904. Substitute the converged variational posterior parameters into the preset logical confidence calculation formula to obtain the logical confidence corresponding to each functional unit; for each functional unit, substitute its converged variational posterior parameters into the logical confidence formula to calculate the scalar form of the logical confidence; the logical confidence formula includes the negative value of the posterior entropy or the maximum posterior probability value; the logical confidence quantification describes the reliability of the derivation results;

[0125] S905. Extract contract candidates with logical confidence scores higher than a preset acceptable lower limit to form a posterior contract distribution; filter out contract candidates with logical confidence scores lower than a preset acceptable lower limit, retaining only high-confidence candidates and their corresponding probabilities to form the final posterior contract distribution; the posterior contract distribution is a set of contract candidates that has been filtered by confidence scores and can be used for subsequent solidification and arbitration.

[0126] Through the above steps, the system integrates symbolic type contract knowledge into the probabilistic reasoning framework, which not only retains the rigor of logical rules but also has the robustness to handle uncertainty and noise, realizing the transformation of type inference from deterministic rule matching to probabilistic knowledge reasoning.

[0127] In some embodiments, after the contract annotation intermediate representation generation module encapsulates the functional unit sequence and the reasons for contract constraint relaxation into a contract derivation confidence warning report, it further includes the following steps:

[0128] S1001. For the functional unit sequence in the contract derivation confidence warning report, extract the contract change frequency and cross-module dependency strength of each functional unit in the historical compilation cycle; from the local contract knowledge base or version control system history, count the number of times the contract annotations of each functional unit in the warning report have been modified in the past N compilation cycles as the contract change frequency; count the sum of its in-degree and out-degree as the cross-module dependency strength; the contract change frequency and cross-module dependency strength quantitatively describe the stability and coupling degree of the functional unit type;

[0129] S1002. Input the contract change frequency and cross-module dependency strength into the pre-set contract vulnerability assessment model to calculate the contract vulnerability index of each functional unit; input the contract change frequency and cross-module dependency strength as input features into the pre-trained contract vulnerability assessment model and output the contract vulnerability index in scalar form; the contract vulnerability assessment model includes a linear regression model or a lightweight neural network; the contract vulnerability index comprehensively reflects the contract volatility and propagation risk of functional unit types.

[0130] S1003. When the contract vulnerability index exceeds the preset vulnerability threshold, the corresponding functional unit is marked as a high vulnerability node; the contract vulnerability index is compared with the preset vulnerability threshold, and functional units that exceed the threshold are marked as high vulnerability nodes; high vulnerability nodes are functional units that have a high maintenance risk at the type contract level.

[0131] S1004. For highly vulnerable nodes, automatically generate contract reinforcement suggestions. For each highly vulnerable node, automatically generate specific reinforcement suggestions based on the reasons for its loose contract constraints and the causes of vulnerability. Contract reinforcement suggestions include the insertion position of explicit type annotations, contract constraint strengthening schemes, and cross-module interface isolation strategies. For example, insert explicit type annotations at key parameter positions, tighten loose generic boundaries into precise types, or split high-frequency change interfaces into stable interfaces and extended interfaces. Contract reinforcement suggestions are actionable, specific type contract optimization schemes for developers.

[0132] S1005. Present contract hardening suggestions in the form of a visual graph in the integrated development environment, and allow users to apply contract hardening suggestions with one click to eliminate weak links in contract derivation; render high-vulnerability nodes, contract hardening suggestions, and related code locations in an interactive graph in the IDE sidebar or pop-up window, and users can click on the suggestion item to automatically insert or modify the corresponding code to complete contract hardening; the visual graph intuitively displays the distribution of contract vulnerabilities and the hardening path;

[0133] Through the above steps, the system not only provides early warnings of confidence decay paths, but also further identifies highly vulnerable nodes and provides reinforcement suggestions that can be applied with one click, transforming passive problem prompts into proactive engineering optimization guidance, thereby improving the maintainability of type contracts and the long-term stability of the system.

[0134] In the specific embodiments of this application, to facilitate understanding of the technical solution, the meanings of the abbreviations, English words, and technical terms appearing in the text are explained as follows:

[0135] IDE: The full name is Integrated Development Environment; it refers to a software tool platform used to write, debug and run data programming code. It integrates a code editor, compiler front-end, version control interface and type inference system plugin provided in this application. It is the main interface carrier for developers to interact with the data type inference system.

[0136] IR: Short for Intermediate Representation, it refers to the structured data format generated by the compiler during the process of converting source code into target machine code, which is between high-level language and low-level instructions; the contract annotation intermediate representation described in this application is an enhanced format that extends the type contract confidence metadata on the basis of standard IR, and is used to transmit type contract data carrying inference information between different stages of the compilation pipeline;

[0137] MLN: short for Markov Logic Network; refers to a statistical relation learning framework that combines first-order logic rules and probabilistic graphical models. It is used to perform joint probabilistic reasoning on symbolic type contract knowledge and observed code features, and is the core algorithmic basis of the probabilistic contract space inference module of this application.

[0138] DAG: Short for Directed Acyclic Graph, it refers to a directed acyclic graph of global contract propagation effects. It is used to depict the unidirectional propagation path and decay relationship of type contract confidence between program functional units. Its acyclic property ensures that there is no circular dependency in the confidence propagation process, and makes the cumulative decay calculation have a definite topological order.

[0139] PCA: short for Principal Component Analysis; it is a linear dimensionality reduction algorithm used to project high-dimensional generic contextual feature vectors generated by graph embedding encoding onto a low-dimensional subspace, reducing the computational dimensionality of subsequent manifold alignment and probabilistic inference while preserving the main variance information.

[0140] CCA: short for Canonical Correlation Analysis; as an optional implementation of manifold alignment transformation, it is used to find the maximum correlation projection direction among three sets of heterogeneous features: type hierarchy relation feature components, generic context feature components, and type guard deterministic feature components, so that they are mapped to a shared low-dimensional manifold space.

[0141] GNN: Graph Neural Network; refers to a deep learning model used to perform node embedding on a type parameter bound path tree. It can encode nodes and their neighborhood relationships in a tree topology into a dense vector representation of fixed dimensions, providing structured feature inputs for subsequent dimensionality reduction and manifold alignment.

[0142] Token: Translated into Chinese as lexical unit; refers to the smallest semantic unit sequence generated by the incremental lexical analyzer after scanning the source code input stream segment, including keywords, identifiers, operators, literals, etc., and is the basic input data for building the program intent topology network;

[0143] Diff: short for Difference, which is translated as difference information in Chinese; refers to the incremental data output by the version control system when it detects code change commit events, describing the added, modified or deleted content of the file. It is used to drive the incremental synchronization channel to capture only the changed part of the source code input stream fragment, avoiding the performance overhead of full parsing.

[0144] JSON: Short for JavaScriptObjectNotation, it is a lightweight data exchange format. In this application, it is used as the standard encapsulation format for contract deduction confidence warning reports. It is used to transmit structured diagnostic data containing functional unit sequences, reasons for contract constraint slack, cumulative decay values, and repair suggestions between type deduction systems and IDE plugins.

[0145] Git: refers to a distributed version control system; as one of the interfaces of the incremental synchronization channel, it pushes code change events to the type inference system through its hook mechanism or application programming interface, and is an external data source for realizing incremental updates of the program intent topology network;

[0146] k-hops: refers to the neighborhood search radius parameter in graph traversal; k represents the maximum number of edges when performing a breadth-first search in the program intent topology network starting from the target functional unit, used to define the range of the cross-module collaborative neighbor set. The value of k is configurable and the default is 2, used to balance arbitration accuracy and computational overhead.

[0147] N times: refers to the statistical window parameter of the historical compilation cycle; N represents the number of historical compilation cycles used to calculate the frequency of contract changes. Its specific value can be dynamically set according to the project scale and change rhythm, providing a statistical basis in the time dimension for the calculation of the contract vulnerability index.

[0148] `extends` is a keyword in programming languages ​​used to declare the upper bound of a generic type parameter. It indicates that the type parameter must be a subtype of a specified type or implement a specified interface, and is used to limit the range of types that can be passed in when instantiating a generic type.

[0149] super: In programming languages, this keyword is used to declare the lower bound of a generic type parameter. It indicates that the type parameter must be the parent type of a specified type and is used to limit the lower bound of the range of types that can be passed in when instantiating a generic type.

[0150] instanceof: refers to the type checking operator in programming languages, used to determine at runtime whether an object is an instance of a specified class or its subclass. It is one of the key syntax elements parsed when this application extracts type guard assertions.

[0151] catch: refers to the keyword in programming languages ​​for exception handling statements, used to catch and handle exceptions thrown in the try block. It is the target syntax structure for this application to track exception catching nodes and extract type guard assertions.

[0152] finally: refers to the keyword of exception handling statement block in programming language. It is a code block that will be executed regardless of whether an exception occurs. In this application, it is used as one of the exception propagation convergence points to merge type predicates on multiple exception paths.

[0153] try-with-resources: refers to an automatic resource management syntax structure in programming languages ​​such as Java, which automatically closes declared resource objects when the try block ends. It implicitly includes exception handling and type checking logic, and is one of the target syntax structures for extracting type guard assertions in this application.

[0154] softmax: Although it does not appear directly in the text, it is related to the formula for calculating logical confidence. It refers to a normalization function that maps any real vector to a probability distribution. It may be used as an underlying computational component when converting variational posterior parameters into class probabilities.

[0155] API: Short for Application Programming Interface, it refers to a predefined interface specification for interaction between software systems. In this application, it specifically refers to the event notification and data query interface exposed by Git or IDE to the type inference system.

[0156] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A data type derivation system for data programming, characterized in that, include: The code intent topology construction module performs cross-module semantic parsing and call contract analysis on the source code input stream to generate a program intent topology network. The implicit contract constraint extraction module traverses the program intent topology network to extract interface polymorphic contracts, generic parameter binding contexts, and type guard assertions within exception handling paths. The type evolution manifold encoding module constructs a dynamic type evolution manifold based on interface polymorphic contracts, generic parameter binding contexts, and type guard assertions. The probabilistic contract space deduction module inputs the dynamic type evolution manifold into the Markov logic network and calculates the posterior contract distribution and logical confidence through weighted first-order logic inference. Compile the load-aware adjustment module and generate a contract derivation granularity control factor based on the functional unit coupling density and the scale of the connected components of the contract derivation subgraph. The contract anchor solidification module selects the contract with the highest joint probability as the anchor contract and generates a contract solidification certificate when the logical confidence level meets the contract derivation granularity control factor. The ambiguous contract arbitration module performs a global contract consistency check and generates a contract arbitration decision when there are multiple candidate contracts with a joint probability difference lower than a preset fuzzy threshold. The contract annotation intermediate representation generation module generates and outputs a contract annotation intermediate representation carrying contract confidence metadata based on the contract solidification certificate and the contract arbitration decision.

2. The data type derivation system for data programming according to claim 1, characterized in that, Traverse the program intent topology network to extract type guard assertions within interface polymorphic contracts, generic parameter binding contexts, and exception handling paths, including: Locate the interaction edges of functional units in the topology network of the program intent, extract the polymorphic implementation candidate set of the interface nodes associated with the interaction edge and the covariance constraints of their return types, as the interface polymorphic contract; The program scans generic instantiation nodes in the intent topology network, extracts the actual binding expressions of type parameters and the upper and lower bound constraints of formal parameters, and constructs a type parameter binding path tree as the generic parameter binding context. By tracing the anomaly capture nodes in the program intent topology network, extracting the type checking predicates and their negations involved in the capture expressions, and combining them with the merging logic of the anomaly propagation convergence point, type guard assertions are generated.

3. The data type derivation system for data programming according to claim 1, characterized in that, Based on interface polymorphic contracts, generic parameter binding contexts, and type guard assertions, a dynamic type evolution manifold is constructed, including: Partial-order set encoding is performed on the subtype compatibility relationship in the interface polymorphic contract to generate type hierarchy relationship feature components; Recursive expansion counting is performed on the nesting depth in the generic parameter binding context, and graph embedding encoding is performed on the type parameter binding path tree to extract the dimensionality-reduced generic context feature components. The number of exclusive type check predicates and the constraint strength of each predicate in the statistical type guard assertion are used to calculate the type guard deterministic feature components. Perform manifold alignment transformation on the type hierarchy relation feature components, generic context feature components, and type guard deterministic feature components, and splice them to generate a dynamic type evolution manifold.

4. The data type derivation system for data programming according to claim 1, characterized in that, When the logical confidence level satisfies the contract derivation granularity control factor, the contract with the highest joint probability is selected as the anchor contract, and a contract solidification certificate is generated, including: Establish a temporary storage area for contract decisions for each functional unit; When the logical confidence level is greater than the contract derivation granularity control factor, the contract solidification priority is determined based on the ratio of the logical confidence level to the contract derivation granularity control factor. Extract the candidate contract with the highest joint probability from the posterior contract distribution, bind the candidate contract to the symbol table slot of the functional unit, and generate a contract solidification record; Write the contract solidification record into the contract decision temporary storage area, and attach a derivation version number and constraint source traceability chain to the contract solidification record as a contract solidification certificate.

5. A data type derivation system for data programming according to claim 1, characterized in that, When multiple candidate contracts have a joint probability difference lower than a preset fuzzy threshold, a global contract consistency check is performed and a contract arbitration decision is generated, including: Extract the cross-module cooperative neighbor set of the functional unit in the program intent topology network. The cooperative neighbor set contains all callers, callees and closure capture variables that directly or indirectly call the functional unit. Calculate the contract compatibility score matrix between the fixed contracts of each node in the cooperative neighbor set and the candidate contracts in the posterior contract distribution; The candidate contract with the highest score in the contract compatibility score matrix is ​​selected as the preferred arbitration contract. Perform cross-module consistency checks on the arbitration preferred contract, and check whether there are contract constraints in the cooperative neighbor set that violate the subtype relationship of the arbitration preferred contract; If there are no contractual constraints that violate the subtype relationship, the preferred arbitration contract will be used as the final derived contract and a contract arbitration decision will be generated; if there are contractual constraints that violate the subtype relationship, the preferred arbitration contract will be marked as a contract to be negotiated and a cross-module contract negotiation protocol will be triggered.

6. The data type derivation system for data programming according to claim 1, characterized in that, After generating the intermediate representation of the contract annotation carrying contract confidence metadata based on the contract solidification certificate and the contract arbitration decision, it also includes: Based on the contract confidence metadata in the intermediate representation of the contract annotation, a directed acyclic graph of global contract propagation influence is constructed. The directed acyclic graph contains the contract dependency edges of all functional units and their confidence decay coefficients. Detect whether there are propagation paths in the directed acyclic graph where the cumulative confidence decays beyond a preset confidence lower limit; When a propagation path is detected where the cumulative confidence decay exceeds the preset confidence lower limit, the sequence of functional units constituting the propagation path and the corresponding reasons for the relaxation of contract constraints are extracted. The functional unit sequence and the reasons for the relaxation of contract constraints are encapsulated into a contract deduction confidence warning report, which is then output to the integrated development environment to prompt users to supplement explicit contract annotations.

7. A data type derivation system for data programming according to claim 1, characterized in that, Perform cross-module semantic parsing and call contract analysis on the source code input stream to generate a program intent topology network, including: Establish an incremental synchronization channel with the version control system; When the version control system detects a code change commit event, it captures differentiated source code input stream fragments through the incremental synchronization channel. Incremental lexical analysis is performed on the source code input stream fragments, only re-parses the affected lexical unit sequences, and retains the cached lexical results of the unchanged parts; Based on a pre-defined program database model, cross-module symbolic link parsing is performed on the incremental lexical analysis results to construct a program intent topology network, and a change timestamp and impact range label are attached to each hyperedge.

8. A data type derivation system for data programming according to claim 4, characterized in that, After writing the contract solidification record to the contract decision temporary storage area, it also includes: Extract evidence of actual contract usage from functional units during subsequent compilation or runtime; Calculate the semantic offset distance between the actual contractual evidence and the anchored contract in the contractual record; The semantic offset distance is compared with a preset contract stability threshold; When the semantic offset distance exceeds the contract stability threshold, the constraint source tracing chain of the functional unit and the offset reason are packaged into a contract deduction evolution sample and injected into the local contract knowledge base to drive the prior distribution of the Markov logic network to be updated adaptively.

9. A data type derivation system for data programming according to claim 1, characterized in that, The dynamic type evolution manifold is input into the Markov logic network, and the posterior contract distribution and logical confidence are calculated through weighted first-order logical inference, including: A contract hierarchy prior graph is constructed in the Markov logic network. The contract hierarchy prior graph includes the inheritance relationship of the language's built-in contract system and the extension relationship of user-defined contracts. Using dynamic type evolution manifolds as observational evidence, weighted first-order logical reasoning is performed on the contract-level a priori graph; Iteratively update the variational posterior parameters of each functional unit until convergence; Substitute the converged variational posterior parameters into the preset logical confidence calculation formula to obtain the logical confidence corresponding to each functional unit. Contract candidates with a logical confidence level higher than a preset acceptable lower limit are extracted and used to form a posterior contract distribution.

10. A data type derivation system for data programming according to claim 6, characterized in that, After encapsulating the functional unit sequence and the reasons for the relaxation of contract constraints into a contract derivation confidence warning report, it also includes: For the functional unit sequence in the contract derivation confidence warning report, extract the contract change frequency and cross-module dependency strength of each functional unit in the historical compilation cycle; Input the contract change frequency and cross-module dependency strength into the pre-built contract vulnerability assessment model to calculate the contract vulnerability index of each functional unit. When the contract vulnerability index exceeds the preset vulnerability threshold, the corresponding functional unit will be marked as a high-vulnerability node. For highly vulnerable nodes, contract hardening suggestions are automatically generated. These suggestions include the insertion position of explicit type annotations, contract constraint strengthening schemes, and cross-module interface isolation strategies. Contract hardening recommendations are presented in the form of a visual graph in the integrated development environment, allowing users to apply the recommendations with one click to eliminate weaknesses in contract derivation.

Images