AU2016100581A4 - Compilation method for linking region-specific computer logic - Google Patents

Abstract

A system that resolves references to the correct functional dependency through a layered set of support libraries, to facilitate regional and customer-specific requirements without changing the core programming language definition, or needing logical branching to identify the correct logic required for each possible decision scenario.

Description

COPYRIGHT NOTICE A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

This invention relates to computer systems and more particularly to language compilers within such computer systems. Even more particularly, the invention relates to a method of linking different sets of functional logic into a single unit when the logical sets to be linked depends on regional requirements (country, legislation, language, region, state).

BACKGROUND OF THE INVENTION

Compilers are programs which run on digital computers to convert one language into another language. Typically, the language being converted, called the source language, is a language that is easily read and understood by a computer programmer skilled in the programming arts. The source language is typically translated into a target language, which is often the machine language for the computer on which the compiler itself runs. The target or machine language is typically understandable only by the computer itself. A compiler typically reads each statement of the source language, and translates that statement into one or more target language statements. Programming languages typically support the creation of functional blocks of logic, often referred to as a Function, Procedure or Method.

When a compiler performs the translation process (compilation) and identifies a token not defined within its standard set of reserved keywords, it will attempt to identify a block of functional logic (a Procedure, Function or Method) named by the same token, and refer to that portion of logic each time that token is referenced. These functional blocks of logic may sit outside the main body of the program and are referenced ("included") implicitly by the programmer as required.

This allows proper structuring of functional blocks of programming logic and enables code reuse by replacing often recurring blocks of logic with a single unit (Procedure, Function or Method) that can instead be referenced each time that logic is required, rather than continuously duplicating the logic.

While this produces a number of benefits for both the programmer and the resulting system, including code reuse, logical simplification and reduction of errors, it does not sufficiently address the problem of minor logic differences that may be required within those functions.

Consider the following pseudocode for performing a mathematical rounding of a number: INT a = Round(51); PRINT a; END; FUNCTION Round(DECIMAL number) { if (number <50) return 50; return 100; }

In the above logic, the Round function returns 50 if the value passed to the function is less than 50, otherwise it returns 100.

During compilation, whenever the compiler detects a token "Round" it will link to the Round function. This saves the programmer from having to repeat the logic contained within the Round function each time it needs to perform this level of rounding.

Consider however, a situation where this method of rounding needs to be performed in 80% of situations, however in the remaining 20% a minor change in logic is required. This problem can be overcome by passing an additional flag along with the value, as shown in the following pseudocode: INT a = Round(51, True); PRINT a; END; FUNCTION Round(DECIMAL number, Boolean RoundingType) { if (RoundingType == True) { if (number <50) return 50; return 100; > else { if (number <40) return 40; return 100; > >

The above example shows how by passing an additional parameter, or even a set of parameters, the inner functional logic can be expanded to handle multiple scenarios.

Now consider situations in programming where functional logic is specific to a geographical region, country or state, for example correct calculation of taxes.

Using the above pseudocode example, the programmer will have to expand the logic drastically to cover the requirements for every possible country, territory, state, region and country as required, resulting in functional logic that is hard to maintain, error-prone and in a production environment nearly impossible to update as legislation or requirements change in any of the possible locales covered by the function, and at any possible time.

An example of this expansion if scenarios are shown in pseudocode below:

SUMMARY OF THE INVENTION

The invention proposes a new method of dynamically linking to the correct block of logic required (Procedure, Function, Method) by using a layered architecture of libraries. Any number of layers can be utilized but for purposes of clarity this document will focus on three, namely CORE, GLS and CUS layers.

The CORE layer defines the standard, default functional logic that the compiler will link to if it fails to detect any similar token (Procedure, Function, Method) named in any of the layered libraries (GLS, CUS).

In the CORE layer, for our example ROUND function, the definition will utilize the standard built-in rounding facility provided by the programming language this invention is implemented in. For example, using the Microsoft C#.NET programming language and framework: public static double Round(double numberToRound) { return System.Math.Round(numberToRound); >

The compiler will by default link any references in the programming code to token Round to its internal Round function, which in turn calls the standard System.Math.Round function as defined in the .NET framework. This is the default behavior.

To overcome regional differences in rounding, an additional layer will be introduced, GLS, which allows third parties to implement a region-specific method of rounding which if detected during compilation, will be referenced instead of the standard rounding defined in the CORE layer. For example: public static double Round(double numberToRound) { ...perform custom regional rounding here... }

During compilation, the compiler will detect calls to a Round token. As Round is not a reserved keyword of the programming language, it will assume it could be a Procedure, Method or Function and using a method called reflection interrogate the GLS layer library thereby detecting an implementation of the Round token as a function, and link to it.

During runtime of the program, all references made to Round will therefore be routed to the Round function implemented within the GLS layered library, not CORE.

When the compiler interrogates the GLS layer library and fails to find an implementation of the specified token (in this example, Round) with the same return type (in this example, double) and the same parameters (in this example, a double input value) it will move upwards to the next layer, being CORE, and perform the same level of interrogation.

If it finds an implementation it will link to it instead. Failing to find any matching implementation results in a compile-time syntax error, which is the normal behavior for any standard compiler.

To further expand, a CUS layer library will be introduced adding an additional layer for customer-specific implementations of tokens (Procedure, Method, Function).

For example, should the standard rounding implemented in CORE not suffice for a specific region, say the state of Queensland in Australia, a region-specific implementation can be added in the GLS layered library.

Multiple GLS layered libraries can exist in a production environment, for example GLS.US.NY.Yonkers and GLS.AU.QLD with the system loading the required library as needed.

Should a customer within the state of Queensland, Australia, require a specific implementation of a function which differs from both CORE and GLS, it can be further defined in the CUS layer library, in the same fashion, with the same name and parameters: public static double Round(double numberToRound) { ...perform customer-unique rounding here... }

During compile time, the compiler will detect a token named Round. The compiler will detect the existence of a layered library named CUS and will proceed to interrogate it first to find a matching implementation of the Round function.

If it succeeds, it will link to it and execute the logic contained within the function during runtime. If it fails, it will move up the layer to any GLS layered libraries it finds, and interrogate them instead.

Should it find a matching implementation, it will link to that implementation and use it during run time instead. Failing any match, it will again move up the layers to the CORE layer and attempt the same matching of tokens. This process can be implemented using any number of layers required and is not limited to the three in this example.

The benefits of this layered method of compile-time linking to matching implementations is in the fact that the underlying functional logic (Procedure, Method, Function) does not require additional parameters.

The token name does not need to identify region or customer specific information. The same overall programming logic can be ported across regional boundaries without requiring recompilation or edit, by simply distributing the required implementations of those functions within the underlying libraries instead.

In a business domain such as payroll and tax processing this offers a substantial advantage and simplification allowing individual processing rules to be defined in a generic fashion and distributed to potentially thousands of customers without any modification.

Additional regional support can be added into live production environments without requiring an upgrade or recompile of overall payroll software component or engine, by simply interchanging the underlying support libraries.

An additional advantage is that there is no runtime performance impact, as linking is done during compilation, not during runtime.

Implementing the above requires compile-time token identification, support library interrogation, matching and linking defined in the language compiler.

An example implementation of token matching to an external layered library as implemented in C#.NET is shown below: private void Method(SourceCodeLine sourcecodeLine, ref int t, Token token) { currentToken = sourcecodeLine.Tokens[t]; string methodName = currentToken.Text; string className = String.Empty; while (methodName.IndexOff1.") > -1) { className += methodName[0].ToString(); methodName = methodName. Remove(0, 1); } className = className.Replacef'.", string symbolName = String.Empty;

Methodlnfo methodlnfo = GetMethodLayerType(className, methodName, ref symbolName); il.Emit(OpCodes.Ldloc_S, symbolTable[symbolName].Locallndex);

HandleLogicalOperators(ref tokenlndex, il, tokens, symbolTable, false); il.Emit(OpCodes.Callvirt, methodlnfo); }

An example implementation of layer library matching of a token to a functional implementation of that token as implemented in C#.NET is shown below: private Methodlnfo GetMethodLayerType(string className, string methodName, ref string symbolName) { if (cusType != null) {

Methodlnfo[] methods = cusType.GetMethods(BindingFlags.Public | BindingFlags.Instance); foreach (Methodlnfo method in methods) { if (method.Name == methodName) { symbolName = "Cus" + className; return method; } } } if (glsType != null) {

Methodlnfo[] methods = glsType.GetMethods(BindingFlags.Public | BindingFlags.Instance); foreach (Methodlnfo method in methods) { if (method.Name == methodName) { symbolName = "GIs" + className; return method; } } } if (coreType != null) {

Methodlnfo[] methods = coreType.GetMethods(BindingFlags.Public | BindingFlags.Instance); foreach (Methodlnfo method in methods) { if (method.Name == methodName) { symbolName = "Core" + className; return method; } } } return null; }

Claims (3)

1. CLAIMS What is claimed is:

   1. A computer implemented method for identifying and linking to the appropriate Function, Method or Procedure based on a set of external libraries structured in a set of layers ordered by priority and relevance, being Customer, Region and Core/Default, said computer implemented method comprising the steps of: a. Token identification during lexical analysis phase of compilation b. Token matched to a non-keyword being a possible Method, Procedure or Function c. An interrogation process of external support library layers consisting of Customer, Region, Core/Default and attempting to match the token to an implementation defined within any of these libraries, order of preference being Customer, Region, Core/Default. d. Upon detecting an implementation within any of the three layered libraries, the direct linking to that specific implementation, and only that implementation. e. The execution of the functional logic defined within that identified implementation during run-time of the program. f. The support layer libraries being able to be replaced, upgraded or recompiled without affecting any logic within the compiled program that references the implementation defined in any of those libraries.
2. 2. A computer implemented method for defining functional blocks of logic with the same token name, return value and set of input parameters, differentiated in their appropriate usage based on relevance and/or priority, that being Customer, Region and Core/Default.
3. 3. A computer implemented method that takes place during time of compilation, not interpretation of programming language.