Derive many conventional programming language interfaces

Abstract

The present invention relates to computer-implemented techniques for deriving many idiomatic programming language interfaces. The techniques allow a programmer to provide idiomatic interfaces in many different programming languages without additional per-language effort. The techniques provide a solution to the technical problem of providing idiomatic interfaces in many different programming languages. Specifically, the techniques solve the problem of providing idiomatic interfaces that use the different definitional elements required by the different programming languages and that are expected in the way a programmer experiences the language.

Description

Technical Field

[0001] The present disclosure relates to source-to-source programming language compilers. More specifically, the present disclosure relates to computer-implemented techniques for deriving many idiomatic programming language interfaces. Background Art

[0002] Computers are very powerful tools for performing a wide variety of tasks. A computer program is a general mechanism for using a computer system to implement a customized processing task. A typical program is a set of programmed instructions (source code) that is compiled into an executable form. Then, the executable form is executed by the computer system to implement the task. For example, a set of C programming language instructions can be compiled into a set of x86 processor-executable instructions. Then, the set of processor-executable instructions can be executed by an x86-compatible processor to implement the processing task.

[0003] Between a set of programmed instructions as programmed by a human computer programmer and the executable form, a compiler is typically used as a translator. In essence, the compiler shields the programmer from having to know or even worry about the underlying executable form details. Generally, all the programmed instructions written by the programmer are translated by the compiler. For example, the compiler can perform type checking, object binding, symbol table construction, register allocation, and instruction scheduling, all of which do not require the programmer to know the underlying compiler implementation. In this way, the compiler provides the programmer with a tool to reason about and express processing tasks at a higher level using a high-level programming language, which alleviates the cognitive burden on the programmer of worrying about low-level execution details. The general construction and operation of compilers are well known in the art. See, for example, "Compilers: Principles, Techniques, and Tools" by Aho, A., Sethi, R., and Ullman, J., second edition, 2007.

[0004] One purpose of some compilers is cross-compilation. A cross-compiler can be defined as a compiler that accepts source code that is both human-readable and computer-readable as input and produces multiple different executable forms of the source code as output. For example, consider a cross-compiler for the C programming language. Such a cross-compiler can produce an x86 executable file (e.g., for execution on a computer configured with the MICROSOFT WINDOWS operating system), an ARM executable file (e.g., for execution on a mobile computing device configured with the ANDROID operating system), and a WASM executable file (e.g., for execution on a virtual stack machine supported by a web browser application) from the C source code.

[0005] Source-to-source compilers also exist. A source-to-source compiler can be defined as a compiler that accepts source code that is both human-readable and machine-readable as input. The compiler output is source code for one or more different source code targets, each of which is also both human-readable and machine-readable. For example, the HAXE compiler can translate source code written in the HAXE programming language into some structurally similar programming language targets. More information about HAXE can be found on the Internet in the haxe.org Internet domain.

[0006] Source code defines interfaces in a programming language, but does not state how to define interfaces in other programming languages. In other words, the interface definition in one programming language does not tell the source-to-source compiler how to define an interface in another programming language. Instead, components of the source-to-source compiler (sometimes called the backend) determine the "plan" or best way to define an interface in the target programming language. The backend is responsible for translating the programming interface definition in the source programming language into an equivalent interface definition in each target programming language. The role of the backend in the source-to-source compiler is to find an appropriate interface definition from the search space of many semantically equivalent alternatives.

[0007] Modern source-to-source compilers mainly focus on overall application development. The set of target programming languages supported by a given source-to-source compiler is usually small and usually structurally related. For example, the HAXE cross-compiler supports JAVASCRIPT, PHP, PYTHON, LUA, C++, JAVA, and C# as programming language targets for web browsers, desktop computers, mobile phones, servers, game consoles, and command-line applications.

[0008] However, in current source-to-source compilers, there are problems with extending to many (e.g., eight or more) programming language targets. On the one hand, different programming languages use different defining elements. For example, C++ provides namespaces, multiple inheritance classes, structures, template functions, default values, and overloading; JAVA provides single inheritance classes, single parameterized interfaces, exceptions, and overloading; PYTHON provides classes, unions, and exceptions; and JAVASCRIPT provides single inheritance classes, objects as namespaces, and exceptions. The interfaces generated by the source-to-source compiler for different programming language targets should each use the defining elements provided by the corresponding language of the interface.

[0009] Another limitation of many current source-to-source compilers for overall application development is that the source-to-source compilers only support a small number of structurally similar target programming languages. Doing so allows the compiler to provide a large source code library to support overall application development. However, the drawback of supporting overall application development is that adding support for additional programming languages requires translating the large library into the new programming language. Such translation can make the effort to support additional programming languages approach the effort required to support a second language.

[0010] What is needed is a technique for deriving many programming language interfaces. The solution should support all widely used programming languages. Additionally, the solution should allow a programmer to generate interfaces without additional per-target language work. The techniques disclosed herein solve this problem and others.

[0011] The methods described in this section are approaches that can be pursued, but not necessarily the approaches previously envisioned or pursued. Therefore, unless otherwise indicated, no method described in this section should be assumed to be prior art merely because it is included in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In the figures of the drawings, the techniques are illustrated by way of example and not by way of limitation, and where like reference numerals refer to like elements, and in each figure:

[0013] Figure 1 Depicts an organizational view of deriving many idiomatic programming language interfaces.

[0014] Figure 2 Is a block diagram of an idiomatic interface generator.

[0015] Figure 3A 、 Figure 3B 、 Figure 3C 、 Figure 3D 、 Figure 3E 、 Figure 3F 、 Figure 3G 、 Figure 3H Collectively are a Unified Modeling Language (UML) diagram of an interlingual definition element category and the inheritance relationships therebetween.

[0016] Figure 4 Is a Unified Modeling Language (UML) diagram providing a linearized input view of a package of interlingual definition elements.

[0017] Figure 5 Is a flowchart of a process for resolving name conflicts in situ.

[0018] Figure 6 Is a block diagram of a two-level picker for resolving name conflicts.

[0019] Figure 7 Is a schematic diagram depicting a promotion.

[0020] Figure 8 is a block diagram of an exemplary basic computing device that can be used in embodiments of the technology.

[0021] Figure 9 is a block diagram of an exemplary basic software system that can be used to control Figure 8 the operation of a basic computing device. SUMMARY OF THE INVENTION

[0022] The general overview section of the detailed description below provides a useful overview of techniques for deriving many conventional programming language interfaces.

[0023] In some embodiments, the interface generator uses a model that defines how elements can be combined to craft an interface for compiler input or output. The model can involve constraints such as in constraint programming or rules such as in rule-based systems or expert systems.

[0024] In some embodiments, the model incorporates a formal grammar. For a programming language similar to the target programming language, or for a language that contains interlingual definition elements corresponding to those available in many target programming languages or translatable to those available in the target programming language, the formal grammar can be generative.

[0025] In some embodiments, the formal grammar is driven to produce alternatives. A search algorithm or a goal-directed planning algorithm can be used to drive the grammar.

[0026] In some embodiments, a model that defines how elements can be combined to craft an interface for compiler input or output is used to filter or refine potentially invalid combinations of definition elements.

[0027] In some embodiments, a model that defines how elements can be combined to craft an interface for compiler input or output uses a plug-in architecture. The plug-in architecture can be used to allow customization of naming, allow a last resort for customizing name conflict resolution strategies, allow customization of the translation of features to definition elements, allow the way interface elements are connected to functional elements, or adjust parts of the compiler input or output. Parts of the compiler input or output can be completed because the target programming language does not allow different names for the same thing, for example, such as hidden names that occur when type definitions are compiled into functional elements and another common name assigned by the interface generator. The plug-in architecture can encompass implementing the default behavior of the interface generator via one or more basic plug-ins. Then, the interface generator can delegate certain tasks to the basic plug-ins.

[0028] In some embodiments, a model that defines how elements can be combined to craft an interface for compiler input or output is input to artificial intelligence techniques that evolve valid and complete combinations of the defining elements based on potentially invalid or incomplete predecessors.

[0029] In some embodiments, the model that defines how elements can be combined to craft an interface for compiler input or output includes placeholders that can be filled with names or identifiers provided when or after the pattern is evaluated. The placeholders can refer to names or identifiers associated with functional elements or can be derived from compiler input. The placeholders can include metadata that specifies that a name of a certain kind is preferred. The metadata can include human part-of-speech tags such as a preferred noun phrase or a preferred interrogative phrase. The metadata includes information about preferred text case. The metadata includes information about a preferred term-combination style such as, for example, lowerCamelCase, UpperCamelCase, under_scored, etc. Portions of the metadata can be references to data not stored in the model itself. For example, the metadata can include a reference to an algorithm.

[0030] In some embodiments, the interface generator uses a corpus of models that define how elements can be combined to craft an interface for compiler input or output. A description of the target programming language can be used to identify an appropriate model for a given target programming language. For example, the description might be "C++". A description of the compiler input or output can be used to find an appropriate model for a given target programming language. For example, a file name ending in ".java" or ".class" indicates that a JAVA model should be used. A machine learning classifier can be applied to the compiler input or output to select a model. The model corpus can include multiple models for a number of target programming languages (e.g., eight or more models for eight or more target programming languages).

[0031] In some embodiments, the interface generator is used in conjunction with a cross-compiler that produces output for multiple target programming languages.

[0032] In some embodiments, the compiler invokes the interface generator.

[0033] In some embodiments, the interface generator is applied separately from the compiler. The interface generator can be applied to the compiler input before compilation. The interface generator can provide output that is then also input to the compiler. The interface generator can be applied after compilation, and then the same compiler or a different compiler can be applied to the output of the interface generator. Outputs from the compiler and the interface generator can be routed through a stand-alone linker.

[0034] In some embodiments, an interface is derived from a group of functional elements. The functional elements may be represented as a bundle of data. The data may include a descriptive name useful for debugging. The data may include a reference to a portion of the compiler input useful for debugging. The data may include definition elements in the language of the interlingua definition elements. The data may include a reference to a portion of the compiler input or compiler output to assist in connecting the definition elements generated by the interface generator associated with this functional element to the computing machine performing the task of the functional element.

[0035] In some embodiments, the functional elements are grouped into functional sets. The evaluation of the functional elements may be based on whether each functional set has elements corresponding to the generated definitions. The functional elements may be grouped into sets based on aspects of the compiler input or compiler output. Metadata in the general specification may specify in which functional set a functional element is. The metadata may be a specially formatted source code comment or annotation that specifies which functional set a functional element belongs to. The source programming language of the general specification may include a specific mechanism for defining functional sets, the defining of the functional sets including definition elements and macros. Naming conventions or lexical scopes may be used to associate functional elements with functional sets. The functional elements may be grouped into sets based on aspects of separate metadata, such as information in a data file in source code revision control, information declared by a build system at a programmer's workstation, or information in a separate database. The functional elements may be found by scanning the compiler input, compiler output, general specification, or separate metadata. A model for the target programming language may include rules for determining which combination of functional set elements completes the set, such as, for example, whether the target has multiple integer types for different machine sizes (e.g., 8-bit, 16-bit, 32-bit, 64-bit, etc.). As another alternative, the target model may specify how to duplicate functional elements for each of the sets, such as, for example, creating 8-bit, 16-bit, 32-bit, and 64-bit integer variants when the target requires them. As yet another alternative, the functional elements may have attached metadata that allows filtering or union in combination with the target model. For example, one target may need to support both 32-bit and 64-bit numbers to be functionally complete, while another target may only need to support 64-bit numbers to be functionally complete.

[0036] In some embodiments, the interface definitions are translated separately from the features and merged into a larger and more complete definition. The decision to merge two interface definitions and what to merge the two interface definitions into may be based on the surrounding context envelope elements.

[0037] In some embodiments, a portion of the interface definition is promoted into the containing element. The decision to promote can be defined based on metadata attached to the definition. The decision of what to promote or to which level to promote can be based on the kind of interface definition. The decision of what to promote or to which level to promote can be based on information contained in the target model.

[0038] In some embodiments, the interface generator is configured to maintain backward compatibility requirements. The stabilizer component of the interface generator can collect stability requirements. The stability requirements collected can be metadata generated by a previous run of the interface generator. That metadata can be generated by the interface generator or by a programmer in a human-readable format and a machine-readable format that can be generated by the interface generator. The metadata can be found in the compiler output or a bundle of compiler outputs. The metadata can be obtained from a common module repository across a network. One or more clients of a previous version can be examined to find what functional elements were actually used. One or more potential future clients can be examined to find what functional elements the potential future clients will use. This may involve scanning source code files in the target programming language or examining compiler errors to look for "XYZ not provided" messages and then inferring what is needed. Stability requirements can be automatically derived from the compiler output, such as when migrating a library that used a manually generated interface in a previous version to a toolchain that includes an automatic interface generator. The interface generator can output information for use by the stabilizer in the future. The information can be emitted in the form of a metadata file. The metadata file can coexist with the compiler input in version control, be stored in a database of version metadata, or be bundled with the compiler output. The information can be embedded in the compiler output or embedded in a bundle with one or more compiler outputs. The information can be patched into the compiler input, such as for example as an annotation or a structured comment, or by replacing or augmenting a previous annotation or structured comment. In some embodiments, source code compatibility requirements are treated separately from binary compatibility requirements.

[0039] In some embodiments, models of human language are used to avoid conflicts or produce more idiomatic names. The model may prescribe preferred verb phrases, noun phrases, or interrogative phrases. The model may include or reference a thesaurus or stemmer to interchange between names. The model may include or reference acronym terminology preferred by the target. For example, JAVA prefers URI, while JAVASCRIPT prefers URL. The model may include or reference a splitter and word recombiner that splits words according to camel case or underscore preference. In some embodiments, top-level name conflicts are resolved by searching a repository. The model may include or reference an affix to resolve name conflicts by attaching a particle to the name. The affix may proactively avoid future name compatibility issues. Decisions or unresolved name conflicts may be presented to a human for adjustment or approval in a graphical or text-based computer user interface, for example.

[0040] In some embodiments, machine learning is used to derive a target model or name based on training examples of an interface. For example, machine learning may be used to derive a target model for a new target programming language or a new dialect of an existing target programming language.

[0041] In some embodiments, a mechanism takes an interface definition and connects the interface definition to functional elements. This connection may occur before compiling the connected interface definition and functional elements. This connection may include generating source code, invoking a third-party compiler or linker, generating binary instructions or bytecode, consuming a bundle of compiler output, or producing a bundle of compiler output. This connection may also involve presenting the connection mechanism to a programmer for approval or adjustment prior to processing, such as in a graphical or text-based computer user interface. Detailed Description

[0042] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the technology. It will be apparent, however, that the technology may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the technology.

[0043] General Overview

[0044] Computer-implemented techniques are described herein for deriving many idiomatic programming language interfaces from a common specification. The techniques allow a programmer to provide idiomatic interfaces in many different programming languages without additional per-language effort. The techniques provide a solution to the technical problem of providing idiomatic interfaces in many different programming languages. Specifically, the techniques solve the problem of providing idiomatic interfaces that use the different defining elements required by the different programming languages and that are expected in the way a programmer experiences the language.

[0045] The techniques described herein may be a computing system, a computer-implemented method, or a non-transitory storage medium, and may include obtaining a set of one or more features extracted from a general specification. For each of a number of programming language targets, an interlingual definition element model for the programming language target is applied to the set of features. The model application generates a set of interlingual definition elements from the set of features and for the programming language target. The set of interlingual definition elements is then translated into an idiomatic interface definition for the set of features and the programming language target.

[0046] These and other aspects of the technology will become apparent from the following detailed description in conjunction with the accompanying drawings, which illustrate the principles of the technology by way of example.

[0047] Glossary

[0048] The following definitions are provided for illustrative purposes and not for limiting purposes to aid in understanding the disclosure of the technology:

[0049] Client: A "client" may be defined as a part of a system that delegates tasks to a library.

[0050] Compiler: A "compiler" consumes an input (such as a program written in a programming language) that is suitable for both human consumption and machine consumption and produces an output that is more suitable for machine consumption.

[0051] Cross-compiler: A "cross-compiler" is a compiler that produces two or more outputs from one input.

[0052] Definition element: A "definition element" may be defined as a building block of a programming language that is provided by the language for crafting an interface in the programming language. Different languages provide different sets of definition elements for crafting interfaces.

[0053] Feature: A "feature" may encompass one or more lexical tokens extracted from a general specification that form a syntactically permissible source programming language construct that will be available to a client in a library as a corresponding syntactically permissible construct in a number of target programming languages.

[0054] Functional element: A "functional element" may be defined as a part of the output of a compiler that a programmer who maintains the compiler input wishes to allow a client to use.

[0055] Interface: An "interface" may be defined as how a client connects to a library. An interface may include one or more interface definitions for connecting to parts of the output of a compiler.

[0056] Interface definition: "Interface definition" can be defined as a set of defining elements in a programming language, the defining elements being sufficient to allow a client to use functional elements.

[0057] Interlingual defining element: "Interlingual defining element" can be defined as a building block for crafting from one or more features of an interface in many different programming languages.

[0058] Library: "Library" can be defined as an expression of one or more algorithms in an automatable form. Examples of automatable forms can be programming language code or its compiled version (e.g., as bytecode, binary executable code, etc.). Generally, when executed as one or more procedures, a library does not "own" the procedures executed as part of it. Instead, a library executes with or as part of a larger system that delegates a particular kind of algorithmic task to the library. For example, a microservice on a computer network can be considered a library. Microservices often exist for other network nodes to offload particular algorithmic tasks.

[0059] Target: "Target" can be defined as a mechanism by which a client connects to the output of a compiler. A programming language can be a target; a programmer writes code to connect to a library loaded into the same memory space. A virtual machine (VM) can be a target; a programmer can write code that is compiled into a kind of bytecode that the VM runs and that depends on the VM to link and use via an interface. Another program can be a client. Thus, an inter-program mechanism is a target; code can use interprocess communication (IPC), remote procedure call (RPC), or a RESTful network protocol to send a message to some program (such as a web service or microservice) running outside of the process of the client program and to discern when an incoming message contains a response.

[0060] Type: "Type" is a defining element used to explain which kind of values are suitable where. For example, a defining element can use a numeric type in one way to indicate that it expects a number (numeric value) as input and in another way to indicate that it produces a number as output.

[0061] Exemplary usage scenarios

[0062] For example, consider the technology usage scenario in a large software development organization with a professional team of many software engineers and data scientists. For example, the organization can have a team of mobile application development engineers, a web application development team, and a data science team. Each of these teams can use different programming languages and related technologies. And across all teams, many different programming languages (e.g., eight or more) can be used. Inevitably, each of these teams will have common problems to solve. The common problems can be related to business requirements that do not belong to or do not require any particular programming language or technology.

[0063] One possible organizational approach to solving problems within an organization is to have each team individually use the programming languages and technologies in which it is most proficient to solve the problems. In addition to duplicate efforts, this approach has other problems. On the one hand, due to the independent nature of each team and the correspondingly different programming languages and technologies used by each team, the possibility of sharing code across teams is limited to non - existent. Additionally, if each team individually translates the business requirements of a common problem, the result may be multiple low - quality, slightly different, and inconsistently maintained solutions.

[0064] In contrast, a common infrastructure team using the techniques disclosed herein can develop solutions for all other teams, including providing solutions in the programming languages with which the teams are experienced and familiar. Specifically, members of the common infrastructure team can write source code specifications embodying solutions to common problems in a single source computer programming language. Thus, the members only need to be experts in the source computer programming language, rather than experts in many computer programming languages.

[0065] At a high level, once the source code specification has been written, according to the techniques disclosed herein, an interface generator extracts a set of features from the common specification. For each desired target programming language, the interface generator applies an interlingual definition element model for the target language to the set of features to produce a set of interlingual definition elements from the set of features and for the target language. For example, if there are ten target languages, up to ten interlingual definition element models can be applied to the set of features. Then, each generated set of interlingual definition elements is translated by the interface generator into an idiomatic interface definition in the target language.

[0066] The idiomatic interface definitions, along with libraries implementing the interfaces generated by the source - to - source compiler, can then be provided to other teams in the organization for integration into their projects. Advantageously, using the techniques, solutions to common organizational problems are centrally solved and distributed to different teams in different programming languages, which are the programming languages with which the different teams are respectively familiar and comfortable working. Additionally, due to the centralized organizational process enabled by the techniques, the above - mentioned problems of having each team individually solve common problems within its own separate team are reduced or eliminated.

[0067] Exemplary System

[0068] Figure 1Describe the organizational usage scenarios that derive many conventional programming language interfaces. Throughout this article, an example of a general infrastructure team is discussed. However, many other usage scenarios of the technology are possible. For example, software developers or programmers in a group of developers or programmers can develop a solution in a source programming language and then use the technology to create versions of the solution in many different programming languages, and then the developers can publish the versions to various online source code repositories such as GITHUB, BITBUCKET, GITLAB, SOURCEFORGE, and so on.

[0069] Returning to the organizational usage scenario, first, a human programmer 102 in the general infrastructure team programs (writes) a general specification 104 in a source programming language. The general specification 104 is suitable as input for a source-to-source compiler 110 and an interface generator 112. The general specification 104 defines how an algorithm is implemented, which provides a solution to a shared organizational problem and also thus declares an interface in both human-readable and computer-readable forms according to the source programming language.

[0070] Once programmed, the general specification 104 is translated (compiled) by the source-to-source compiler 110 into many target implementations 114-1, 114-2,..., 114-N of the algorithm in many different target programming languages. For example, the target programming languages can encompass widely used languages such as, for example, all of the following programming languages, subsets of these languages, or supersets thereof: C, JAVA, PYTHON, C++, C#, JAVASCRIPT, PHP, SWIFT, R, LISP, FORTRAN, ADA, PASCAL, GROOVY, RUBY, GO, OBJECTIVE-C, DART, SCALA, and LUA.

[0071] The general specification 104 is also translated (compiled) by the interface generator 112 into many target interfaces 116-1, 116-2,..., 116-N. When connected together, the target interfaces and target implementations form a target library in the target programming language, which is available for target clients to use. In Figure 1 the example, the target library 118-1 is composed of the connection of the target-1 interface 116-1 and the target-1 implementation 114-1, the target library 118-2 is composed of the connection of the target-2 interface and the target-2 implementation 114-2,..., and the target library 118-N is composed of the connection of the target-N interface 116-N and the target-N implementation 114-N. For example, the target library 118-N can be a JAVA source code library, the target 118-2 can be a PYTHON source code library,..., and the target 118-N can be a C++ source code library.

[0072] The target clients 108-1, 108-2, ..., 108-N can be computer programs programmed in the target language by the corresponding human programmers 106-1, 106-2, ..., and 106-N. For example, programmer 106-1 can be in the enterprise software team of an organization that programs the target-1 client 108-1 in the JAVA programming language. Continuing with the example, programmer 106-2 can be in the data science team of an organization that programs the target-1 client 108-2 in the PYTHON programming language, and programmer 106-N can be in the embedded systems team of an organization that programs the target-N client 108-N in the C++ programming language.

[0073] It should be noted that the target clients 108-1, 108-2, ..., 108-N can be programmed to perform completely different tasks. For example, the target-1 client 108-1 can be programmed to perform enterprise software tasks, the target-2 client 108-2 can be programmed to perform data science tasks, and the target-N client 108-N can be programmed to perform embedded systems tasks. Nevertheless, the target clients 108-1, 108-2, ..., 108-N may require general functionality provided by the target libraries 118-1, 118-2, ..., 118-N in different programming languages. For example, the general functionality can be specified by the business requirements of the organization, such as information security or privacy compliance, or just the basic functionality required by many target clients.

[0074] The target clients 108-1, 108-2, ..., 108-N can be connected to the target implementations 114-1, 114-2, ..., 114-N of the target libraries 118-1, 118-2, ..., 118-N via the target interfaces 116-1, 116-2, ..., 116-N of the target libraries 118-1, 118-2, ..., 118-N respectively. Specifically, the target-1 client 108-1 can be connected to the target-1 implementation 114-1 via the target interface 116-1, the target-2 client 108-2 can be connected to the target-2 implementation 114-2 via the target interface 116-2, ..., and the target-N client 108-N can be connected to the target-N implementation 114-N via the target interface 116-N.

[0075] The connection between the target client and the target interface can be made via the application programming interface (API) of the target interface generated by the interface generator 112 in the target programming language. Specifically, the interface generator 112 uses the techniques described herein to generate APIs in a number of target programming languages that would be recognized as idiomatic by developers of the particular target language. For example, if the target programming language of the target library 118-1 is JAVA, then as a representative member of the JAVA programmer community, the programmer 106-1 can recognize the API of the target-1 interface 116-1 as idiomatic to the JAVA programming language; if the target programming language of the target library 118-2 is PYTHON, then as a representative member of the PYTHON programmer community, the programmer 106-2 can recognize the API of the target-2 interface 116-2 as idiomatic to the PYTHON programming language;...; if the target programming language of the target library 118-N is C++, then as a representative member of the C++ programmer community, the programmer 106-N can recognize the API of the target-N interface 116-N as idiomatic to the C++ programming language.

[0076] Alternative target

[0077] A programming language is an example of a target. However, the techniques are not limited to programming language targets. More generally, a target can be defined as a mechanism for connecting to the compiler output (e.g., the target implementation of a target library). From this broader perspective, a virtual machine (VM) or an interprocess communication (IPC) mechanism can be a target.

[0078] In the case of a virtual machine, the general specification 104 can contain source programming language instructions compiled by the source-to-source compiler 110 into target implementations 114-1, 114-2,..., 114-N for different target virtual machine platforms. For example, the target implementation can contain a bytecode translation of the general specification 104 that can be interpreted or executed by a particular target virtual machine platform. Also in the case of a virtual machine, the interface generator 112 can generate target interfaces 116-1, 116-2,..., 116-N (e.g., link interfaces) for different target virtual machine platforms that allow the corresponding platforms to connect to (e.g., link to) the corresponding target implementations.

[0079] In the case of inter - process communication (IPC), the general specification 104 may include source programming language instructions that are compiled by a source - to - source compiler 110 into target implementations 114 - 1, 114 - 2, ..., 114 - N for different programming languages. The source programming language instructions may also be processed by an interface generator 112 into target interfaces 116 - 1, 116 - 2, ..., 116 - N for different target programming languages. However, the target libraries 118 - 1, 118 - 2, ..., 118 - 3 may execute as web services or microservices, etc. In this case, instead of the target clients 108 - 1, 108 - 2, ..., 108 - N connecting to the target libraries 118 - 1, 118 - 2, ..., 118 - 3 via an API, the target clients 108 - 1, 108 - 2, ..., 108 - N may connect to the target libraries 118 - 1, 118 - 2, ..., 118 - 3 that execute as web services or microservices via a network remote procedure call (RPC) protocol, such as, for example, Representational State Transfer (REST), SOAP, XML - RPC, JSON - RPC, etc.

[0080] Exemplary source programming language

[0081] The source - to - source compiler 110 and the interface generator 112 may each have a front - end component for parsing and processing the general specification 104 in the source programming language and producing an intermediate representation thereof for further processing by the back - end. For each of the N target programming languages supported, there may be a back - end.

[0082] Each back - end may be responsible for generating the corresponding target implementation (in the case of the source - to - source compiler 110) and the corresponding target interface (in the case of the interface generator 112) in the corresponding target programming language. The target implementation and the target interface may be generated from the intermediate representation produced by the front - end. As two examples, together with associated metadata, the intermediate representation may encompass an abstract syntax tree (AST) - based representation or a bytecode - based representation.

[0083] For example, the source-to-source compiler 110 may have a first backend for generating the target implementation 114-1 in the JAVA programming language, a second backend for generating the target implementation 114-2 in the PYTHON programming language, and a third backend for generating the target implementation 114-N in the C++ programming language. Similarly, the interface generator 112 may have a first backend for generating the target interface 116-1 in the JAVA programming language, a second backend for generating the target interface 116-2 in the PYTHON programming language, and a third backend for generating the target interface 116-N in the C++ programming language. Although only three target programming languages are mentioned in this example, the source programming language, the source-to-source compiler 110, and the interface generator 112 are specifically designed to support many programming languages, such as, for example, all widely used programming languages. In that case, N may be numbered ten, twenty, thirty, or more.

[0084] Although in some embodiments, the source-to-source compiler 110 is a separate and distinct component from the interface generator 112, in other embodiments, the source-to-source compiler 110 and the interface generator 112 are integrated in the same component. In these cases, the source-to-source compiler 110 and the interface generator 112 may share the same front-end and back-end components.

[0085] The source programming language may be a general-purpose language that supports various programming language constructs. To support source-to-source compilation for many target programming languages, the source programming language may have various features that support the flexibility of the source-to-source compiler 110 and the interface generator 112 to translate the general specification 104 in the source programming language into many different target programming languages and to accommodate the various differences that exist across widely used target programming languages.

[0086] As an example of some of the differences across widely used languages, while many widely used target programming languages have managed memory capabilities such as garbage collection, some do not (e.g., the C programming language). As another example, there is no universal concurrency mechanism, such as threads, available across widely used target programming languages. As yet another example, strings are represented differently by different languages (e.g., UTF-8, UTF-16, or UTF-32), such that the atomic unit for efficiently (e.g., in O(1) time) randomly accessing characters in a string has a different size for different languages (e.g., one, two, or four bytes). Some target programming languages provide reliability or security guarantees that other languages do not. For example, if a program is written in the JAVA language and attempts to access data outside the bounds of an array, an exception will be thrown. However, a program in the C language does not provide such protection. As another example, some languages provide protection against integer overflow and underflow, while others do not. Different target languages can have different semantics for the same simple syntax. For example, the semantics of 'x+1' and 'x<y' vary across target languages. Different target languages can use the same keyword terms (e.g., 'class' and 'type'), but with different meanings. Different target languages have different community standards regarding what constitutes good programming style. Different target languages provide different mechanisms for expressing error conditions (e.g., via return values, via global error codes, or via exceptions).

[0087] Features of the source programming language can support these variations among the target programming languages.

[0088] Source programming language - value

[0089] When generating the intermediate representation of the general specification 104, the front end of the source-to-source compiler 110 or the interface generator 112 may need to pass information to the back end regarding when a value programmed in the general specification 104 (e.g., a variable value) can be assumed to conform to a type available in the target programming language or otherwise be suitable for some operation available in the target programming language.

[0090] Source programming language - integer value

[0091] The integer types in the source programming language can be based on arbitrary precision arithmetic, also known as "bignum". This allows the source programming language to interoperate with the native data types of various back ends. Specifically, this allows the source programming language to interoperate with all of the following: the 53-bit integer arithmetic of JAVASCRIPT, the native bigint of PYTHON and RUBY, the integer types of OCAML, the 32-bit native integer types of most other target languages, and the signed or unsigned integer types in those target languages that support them.

[0092] The backend for a given target programming language may need to determine whether a given numerical value programmed in the general specification 104 can fit into a native digital representation of a fixed size (e.g., 32-bit or 64-bit representation). In this case, the backend can use the native digital representation of the fixed size to represent the value in the target programming language.

[0093] As another example, the backend may need to determine whether a given string value programmed in the general specification 104 can be assumed to be a randomly accessible sequence of one of UTF-8, UTF-16, or UTF-32 code units. In a case where the source programming language uses the same code unit size as the target language, the backend for the target language may directly map the string value to the string data type in the target programming language.

[0094] To support accurate, high-throughput parsing of complex, nested languages (such as HTML / JS / URI) that use different-sized code units, the source programming language can provide a buffer type that is accessed via a cursor rather than an index. Since a cursor cannot be arithmetically forged, a UTF-xx cursor is guaranteed to land on a UTF-xx code unit boundary.

[0095] The use of the buffer type in the source programming language also supports the concurrent approach of the source programming language. Specifically, one coroutine can have a read buffer view of the same shared memory region, while another coroutine can have a write buffer view.

[0096] In cases where non-linear access to the buffer is desired, such as when processing binary data (e.g., image data), the source programming language can treat binary format processing as a special kind of non-string buffer, where a cursor can be created from a number.

[0097] As yet another example, the backend may need to determine whether all values of a composite data type (e.g., such as a class or a struct) declared in the general specification 104 each have a fixed upper bound on their size, which can be determined by the frontend based on the value declarations in the general specification 104. In such a case, the backend for the target language can allocate the values on the stack, heap, or data segment according to the best allocation strategy determined by the backend.

[0098] As yet another example, the backend for the target language may need to determine whether a value can be passed by value or by reference. For example, consider a non-address-pointing value (non-pointer value) that is passed to a function in a function invocation but not modified by the receiving function as programmed in the general specification 104. In this case, the backend for the target language may be able to choose between passing the value by reference or passing the value by the most suitable value for the target language.

[0099] The intermediate representation generated by the front end may contain information for the back end to make one or more of the above exemplary determinations.

[0100] Source programming language – Lifetime inference

[0101] A back end for a target language that supports closure conversion may need to determine whether a value defined in a function programmed in General Specification 104 will be needed at runtime after the function completes. If not, then the back end may have more options for closure conversion of the function. Additionally, if the value is no longer needed at runtime after the function completes, then a pointer to the location of the value on the stack can be safely passed to other functions invoked from within the function.

[0102] The intermediate representation generated by the front end of the source-to-source compiler 110 or the interface generator 112 may contain information for the back end to make this determination.

[0103] Source programming language – Deallocation

[0104] The source programming language may support deallocation. For a memory-safe target language, values stored on the stack or in the heap should be deallocated exactly once at runtime rather than before their last use. For a memory-unsafe target language (e.g., the C programming language), the source programming language should support the programmer to work separately so as to cooperate on a program that deallocates values exactly once and not too early.

[0105] Both memory-safe and memory-unsafe target languages can be supported by the source programming language by using a type system that requires an acyclic object graph. This allows reference counting to deallocate values on the stack and in the heap in a timely (not too early) and safe (exactly once) manner. For a target programming language that supports garbage collection, values programmed in General Specification 104 can be allocated by the back end in a garbage-collected memory region for such a target language. For a target programming language that does not provide garbage collection, the back end can implement reference counting semantics for values.

[0106] Source programming language – Concurrency safety

[0107] Many target languages support multi-word values (e.g., values greater than 32 bits). In this case, some of these target languages support multi-word values by splitting the runtime write of a value to a processor register or memory into multiple separate single-word writes. For example, the write of a 64-bit value can be split into two single 32-bit writes at runtime. Similarly, multi-word reads can be split.

[0108] In the absence of concurrency control, if two parts of a computer program written in the target language (e.g., two threads) run simultaneously, and one is writing a word of a multi-word value while the other starts reading the multi-word value, the reader may obtain a mixture of a part of the previous multi-word value and a part of the new multi-word value, which is neither the entire previous multi-word value nor the entire new multi-word value. Such a read is most likely to cause the computer program to behave abnormally, if not fail completely (crash). Thus, the source programming language may support coroutines for dividing work into subtasks that can be executed safely concurrently, and allow the programmer of General Specification 104 to prevent race condition problems similar to the multi-word problem just described above.

[0109] To support concurrent safety, the source programming language may allow the programmer of General Specification 104 to create mutable instances of a class type from which immutable equivalents can be derived. The immutable equivalents can be safely operated on concurrently at runtime. For example, consider the following class definition:

[0110]

[0111] Following this definition, General Specification 104 can create an instance of Point as follows:

[0112] 00: let p = new Point { X: 10, y: 20};

[0113] And since the instance p is mutable, General Specification 104 can adjust the instance as follows:

[0114] 01: p.x += 1;

[0115] General Specification 104 can return the instance p as immutable for concurrent safety as follows:

[0116] 02: return p as Immutable;

[0117] Source Programming Language - Memory Safety

[0118] In many target languages, a pointer or reference to an object in memory typically can only point to or refer to the start or origin of the object as allocated in memory. However, other programming languages (e.g., C) allow so-called fork pointers. A fork pointer can point to or refer to the start, middle, end, or even outside the boundary of an allocated object. For example, a programmer can write a C program that performs pointer arithmetic. Although fork pointers can be useful and efficient for certain operations, if the fork pointer is not programmed correctly, then the fork pointer is not memory-safe. For example, an incorrectly programmed fork pointer can cause the program to fail or crash at runtime. For memory safety, the source programming language may not support fork pointers.

[0119] Source programming language - global variables

[0120] The source programming language may not allow arbitrary types of global variables. Instead, global variables are either: (a) initialized at runtime before being read for the first time when a module or file is loaded, or (b) one of a predefined set of concurrency-safe data types. By doing so, the source programming language can use reference counting for most data types and atomic reference counting where concurrency is required, while also allowing a JAVA backend or another similar backend to utilize types such as JAVA's AtomicLong type or ConcurrentHashMap type to handle global variables.

[0121] Source programming language – inheritance

[0122] Some target languages are object-oriented. Such languages typically allow inheritance through mechanisms such as classes and subclasses. For example, a subclass of the following C++ class can inherit state (e.g., the value of int x) and behavior (e.g., how the get() function is implemented).

[0123]

[0124] Some object-oriented target languages allow single inheritance of both state and behavior. Some object-oriented target languages allow multiple inheritance of behavior but only permit single inheritance of state. For example, the JAVA programming language provides interfaces that support multiple inheritance of behavior and classes that support single inheritance of both state and behavior.

[0125] To support both object-oriented and non-object-oriented target languages, the source programming language can support code reuse and single and multiple inheritance of behavior through traits. However, the source programming language may not support state inheritance due to semantic differences between seemingly similar programming constructs across different object-oriented languages. For example, some object-oriented languages support the concept of constructor chaining but with different semantics. As another example, some object-oriented languages support the concept of information hiding but also with different semantics.

[0126] Source programming language – function overloading

[0127] Some target languages support function overloading. For example, in the JAVA programming language, a programmer can define two functions with the same name but declare different input types for the formal parameters of the function, as in the following example:

[0128] 00: class Foo{

[0129] …

[0130] 01: void say(String message){...}

[0131] 02: void say(int i){...}

[0132] …

[0133] 03:}

[0134] In the above example, calling say("some string") elsewhere in the JAVA program can match the correct say() function at compile time through function signature matching. Specifically, in this example, since the call to say() passes a String type as an argument, the JAVA compiler can determine that the say(String message) function should be called by the call at runtime, rather than by other say functions that accept an integer as an input parameter.

[0135] On the other hand, the above function overloading is possible in the JAVA programming language but not in other languages (e.g., JAVASCRIPT). In this case, the programmer can explicitly program runtime type matching into the function, as in the following JAVASCRIPT example:

[0136]

[0137] To support both target languages that support function overloading and target languages that do not support function overloading, the source programming language can support umbrella functions, which are a type of multimethod of a class that allows the front end to group similarly named functions together so that the back end can generate the most appropriate type of code and take advantage of any function overloading capabilities of the target programming language.

[0138] To support run-time "function overloading" in a target language that does not provide compile-time function overloading, function invocation can be handled by an umbrella function in a source programming language. The umbrella function can collect a set of functions with the same invocation convention. At run-time, the umbrella function can be invoked (called) in two phases: First, the umbrella function can perform tests on its arguments to select one of the actual functions, methods, or programs it has collected; and second, the selected function, method, or program is invoked, and its result is used as the result of the umbrella function call. Since the umbrella function may perform only a limited number of tests in the first phase, for a particular invocation's backend, the number of possible covered functions that could be picked as one may be narrowed down based on type information. Backends for target languages that support compile-time function overloading (e.g., JAVA) may attempt to predict the function that the umbrella function will pick at run-time for a particular invocation and translate the particular invocation into the predicted function. For backends of target languages that do not support compile-time function overloading (e.g., the backend of JAVASCRIPT), these backends can compile the umbrella function into a single function that performs the two phases.

[0139] Interface generator

[0140] Figure 2 is a block diagram of interface generator 112. Interface generator 112 includes a feature extractor 222 that extracts features 224 from a general specification 104. In addition to extracting features 224 from general specification 104, feature extractor 222 groups features 224 for functional completeness. That is, feature extractor 222 can ensure that general specification 104 has provided some minimum functionality that covers the expected functional scenarios of a particular library. For example, if general specification 104 is intended to provide a mathematical absolute value library, then feature extractor 222 can ensure that general specification 104 has provided at least one defining element for each of the functional scenarios of determining the absolute value of an integer and determining the absolute value of a rational number.

[0141] A corpus 228 of target models is provided in a computer storage medium (e.g., as a file stored in the computer storage medium). Although depicted as separate from interface generator 112 in Figure 2 corpus 228 can be a component of interface generator 112.

[0142] The interface generator 112 also includes a picker 220 for generating a target interface for each target language. Given the feature 224 and the target model of the target language as inputs, the picker 220 generates the target interface of the target language. The picker 220 uses the target models 226-1, 226-2,...., 226-N of different target languages retrieved from the corpus 228 to generate the interface definitions of the target interfaces 116-1, 116-2,..., 116-N of different target languages based on the feature 224. This may involve the picker 220 generating interlingual definition elements from the feature 224 and then translating the generated interlingual definition elements into idiomatic interface definitions of different target languages, and the idiomatic interface definitions may be combined with the functional elements generated by the source-to-source compiler 110 for different target languages. Specifically, the picker 220 represents the feature 224 as interlingual definition elements and then generates the interface definitions of different target languages through the process of translating the interlingual definition elements into idiomatic interface definitions that follow the interface definition rules of the target.

[0143] The target models 226-1, 226-2,...., 226-N may cover different definition elements defined in different target languages. The picker 220 generates the target interfaces 116-1, 116-2,..., 116-N that use different definition elements of different target languages. For example, the picker 220 may generate a target interface for the C programming language that uses structs but does not use classes, namespaces, overrides, defaults, or tuples. On the other hand, the picker 220 may generate a target interface for the JAVA programming language that uses classes and overrides but does not use structs, namespaces, functions, defaults, or tuples.

[0144] The target interfaces 116-1, 116-2, …, 116-N generated by the picker 220 are idiomatic. That is, the target interfaces conform to what programmers expect in the target language as to what makes a good interface. Different groups of programmers for different languages have different criteria for what makes a good interface. The picker 220 can generate the target interfaces 116-1, 116-2, …, 116-N that take these different criteria into account. For example, the picker 220 can generate a target interface in the JAVA language that uses overloading and uses classes to group similar concerns. The picker 220 can generate a JAVASCRIPT target interface that uses classes only for defining types of things, uses polymorphic functions to address the lack of overloading, and groups similar concerns via namespace objects or modules. The picker 220 can generate a C target library that uses a set of naming conventions involving prefixes and suffixes of function names to address the lack of namespaces or overloading. The picker 220 can generate the target interfaces 116-1, 116-2, …, 116-N that follow different conventions that different languages use to combine multiple words into compound terms. The picker 220 can generate the target interfaces 116-1, 116-2, …, 116-N that follow different conventions for different kinds of defining elements of a particular target language. For example, the picker 220 can generate any of the following compound term forms depending on the convention for a particular kind of defining element and the particular target language at hand: firstWordLowerCased (also known as camel case), FirstWordUpperCased (also known as Pascal case), words_separate_by_underscores, and UNDERSCORES_BUT_ALL_CAPITALIZED. The picker 220 can generate one or more of the target interfaces 116-1, 116-2, …, 116-N that convey failure by producing results via exceptions, as most modern programming languages do. However, the picker 220 can also generate target interfaces that convey failure by producing results via another mechanism, such as, for example, for the C, GO, or RUST languages.

[0145] An example where the general specification 104 defines a math library in a source programming language is considered. In this case, the general specification 104 can define two functional elements: (1) one for calculating the absolute value of a given integer value; and (2) another for calculating the absolute value of a given floating-point value. Given this example, the picker 220 can generate the following idiomatic interfaces for the target language example:

[0146]

[0147] As can be seen from this example, the picker 220 can generate target interfaces 116-1, 116-2, …, 116-N that take into account differences across target languages in the number of required function definitions, the words used in the definitions, the punctuation used, and whether the input is before or after the operator name.

[0148] The picker 220 can also generate target interfaces 116-1, 116-2, …, 116-N that take into account differences across target programming languages in the rules for when words such as, for example, "abs" can be used in two definitions without interfering with each other. For example, the JAVA language allows classes, methods, and variables to have the same name without interfering with each other, but JAVASCRIPT does not.

[0149] The picker 220 can also generate secure target interfaces 116-1, 116-2, …, 116-N. For example, the picker 220 can use extension functions to generate an interface in the style of x.abs() in the KOTLIN programming language. On the other hand, for JAVASCRIPT, the picker 220 can avoid prototype patching, which is considered less secure than the style used for JAVASCRIPT in this example.

[0150] Interlingual definition element categories

[0151] There may be a predefined set of interlingual definition element categories used by the picker 220 that serve as models for interlingual definition elements for translating between features 224 extracted from the general specification 104 and definition elements in many different target programming languages. An interlingual definition element can be defined as an instance of an interlingual definition element category in the predefined set of interlingual definition element categories. The categories in the predefined set may vary depending on the set of target languages at hand.

[0152] Figure 3A , Figure 3B , Figure 3C , Figure 3D , Figure 3E , Figure 3F , Figure 3G , Figure 3H are Unified Modeling Language (UML) diagram representations of a predefined set of interlingual definition element categories. The set of interlingual definition element categories allows for the representation of features of many widely used target languages. However, depending on the specific set of target languages at hand, a subset or superset of this set of categories may be used. The arrows in the UML diagram represent inheritance (derivation) relationships between different interlingual definition element categories. For example, in Figure 3AIn it, the "Archive" element category is derived from the "AbstractFileContainerElement" category, the "AbstractFileContainerElement" category is derived from the "AbstractFileElement" category, and the "AbstractFileElement" category is derived from the "InterlinguisticDefinitionalElement" category. According to the inheritance relationship, the "Archive" element is also an "AbstractFileContainerElement", an "AbstractFileElement", and an "InterlinguisticDefinitionalElement".

[0153] Figure 3A Show the "InterlinguisticDefinitionalElement" category and the "AbstractFileElement" category derived from it. As shown, the "AbstractFileElement" has the attribute "fileName" of the category "FileName". There are two derivations of the "AbstractFileElement" category: the "RegularFile" category and the "AbstractFileContainerElement" category. The "RegularFile" element represents a file containing text data or binary data. The "RegularFile" element has the attribute "contents", which is a list of elements of each of the "AbstractSourceElement" categories. The "AbstractFileContainerElement" has the attribute "contents", which is a list of elements of each of the "AbstractFileElement" categories. The "AbstractFileContainerElement" category has two derivations: the "Archive" category and the "Directory" category. An "Archive" element instance represents a regular file containing other files, such as a compressed file archive in ZIP or TAR format. A "Directory" element instance represents a folder that can contain other regular files or directories.

[0154] Figure 3BShow the "AbstractSourceElement" subcategory of the base category "InterlinguisticDefinitionalElement". One subcategory of "AbstractSourceElement" is the "SimpleValue" subcategory, which has five subcategories: "TruthValue", "TextualValue", "NumericalValue", "FileReference", and "NullValue". A "SimpleValue" element represents a value that can be expressed in all target languages. For example, all target languages allow the expression of text values (e.g., as strings), numerical values (e.g., as integers), truth values (e.g., as booleans), and missing values (e.g., as null or none), even if the target language does not explicitly provide a separate type for each of these. "FileReference" has a property "fileNames", which is a list of elements of the category "FileName" that are used to refer to "FileName" elements.

[0155] Figure 3CShow the subcategory "AbstractInnerSourceElement", which is also a subcategory of the "AbstractSourceElement" subcategory. "AbstractInnerSourceElement" has a property "contents", which is a list of elements of the category "AbstractSourceElement". There are three subcategories of "AbstractInnerSourceElement", which are: "AbstractDefinition", "Namespace", and "TypeReference". The "Namespace" element represents a named group of definition elements. For example, a definition element within a namespace can be referred to by combining the name of the namespace and the name of the definition element around a target-specific combination punctuation. The "TypeReference" element represents a reference to a type by name. The "AbstractDefinition" element represents a named definition, which can be expressed in all target languages. The "AbstractDefinition" element, the "Namespace" element, and the "TypeReference" element each have a property "Name" of the category "Name". There are four subcategories of the "AbstractDefinition" subtype: "TypeFormal", "TypeDefinition", "Property", and "Procedure". The "TypeFormal" element represents the definition of a generic type parameter, including its name, any restrictions on the types that can be bound to it, and its variance. As Figure 3E depicted in, the "TypeFormal" element has a property "variance" of the category "TypeVariance". The "TypeDefinition" element represents the definition of a type. As Figure 3F depicted in, the "TypeDefinition" element has a property "kind" of the category "TypeDefinitionKind". The "Property" element represents a definition element of an interface that allows reading or writing facts about a value. The "Property" element has three properties: a "kind" property of the category "PropertyKind", which indicates whether the "Property" element is computed (by executing instructions) or stored (as bits in memory), as Figure 3Gdepicted in; a "readable" attribute of type "Boolean", which indicates whether the programmer intends for the defined element to be readable by a programmed instruction that does not have privileges relative to the container of the defined element; and a "writeable" property of category "Boolean", which indicates whether the programmer intends for the defined element to be writable by a programmed instruction that does not have privileges relative to the container of the defined element. For example, the keywords used in various programming languages to define or declare instance variables of a class definition can indicate whether the instance variable is readable or writable by non-privileged code (e.g., code outside of the class definition). For example, in the JAVA and C++ programming languages, the keyword "private" for an instance variable in a class definition specifies that code outside of the class definition cannot directly read or write to the instance variable. C# provides the "readonly" keyword, which can be used to define or declare a read-only property. A "Procedure" element represents the definition of a program or function. As Figure 3D depicted in, the "Procedure" element has an attribute "kind" that belongs to the category "Proce dureKind".

[0156] Figure 3DShow the "ProcedureKind" type with five subtypes representing different kinds of program definitions. The "Detected" element represents the definition of a program that is not tightly associated with one type over another, such as, for example, global or module-level functions in JAVASCRIPT. The "Related" element represents the definition of a program that is tightly associated with a particular type, but does not consider one of its inputs as the subject, but rather other inputs as the object. For example, a programmer using a target language that differentiates between types and instance programs may expect to mention the type name when referring to a related program, such as, for example, via a static method in JAVA. The "Factory" element represents the definition of a program that is associated with a type and is used to produce values of that type. Programs of this type may correspond to constructors in some target languages. Programmers using a target language that uses the reserved keyword "new" to create values may expect to use factory programs to do so. The "Intrinsic" element represents the definition of a program that is naturally part of a particular type. Programmers using an object-oriented target language may expect to access the program via dot notation syntax, such as, for example, "subject.procedureName(object))". Programs may be overridden or changed in subtypes (subclasses). The "Extrinsic" element represents the definition of a program that is naturally part of a particular type. However, unlike the "Intrinsic" element, the program represented by the "Extrinsic" element cannot be overridden or changed in a subtype (subclass). For example, the difference between an external program and an internal program is similar to the difference between a KOTLIN method and an extension function.

[0157] Figure 3E Show the "TypeVariance" subtype, which has three subcategories of type variables representing different kinds of generic type parameters. The "Variant" element represents a generic type parameter that can be bound to the specified type, as well as to a type more derived than the specified type. The "ContraVariant" element represents a generic type parameter that can be bound to the specified type, in addition to being bound to a type less derived than the specified type (a more generic type). The "Invariant" element represents a generic type parameter that can only be bound to the specified type.

[0158] Figure 3FShow the "TypeDefinition" subcategory with three subcategories representing different kinds of types. The "Concrete" element represents a type from which values can be derived. The "AbstractStateful" element represents a type that defines or declares behavior and state, but values cannot be directly derived from it. Values of this type can only be derived from concrete subtypes. The "PureAbstract" element represents a type that defines or declares only behavior.

[0159] Figure 3G Show the "PropertyKind" subcategory with two subcategories representing two different kinds of "Property" elements from which they are derived. The "Backing" element represents a stored "Property" element (e.g., as bits in memory). The "Computed" element represents a computed "Property" element (e.g., by executed instructions).

[0160] Figure 3H Show the "Name" category with three properties: "useContext" of category "NameUseContext", "originalText" of type String, and "uniqueId" of type Int (for integers). The "FileName" category has a "text" property of type String. And there is the "NameUseContext" category representing a set of information that a name resolver might use to resolve name conflicts. Such information can include, for example, the expected part of speech, the expected connection style (e.g., lowerCamelCase or UPPER_UNDERSCORED), disallowed names, or a name conflict mask. The name conflict mask can be a bit mask used to determine whether two names in the same lexical output range interfere. For example, JAVA might use different masks for fields and methods because the JAVA language separates the masks.

[0161] Generative grammar example

[0162] The target model for the target language (e.g., 226-1) can instruct the picker 220 how to generate an interlingual definition element representation of the feature 224 such that the interlingual definition element representation can be translated into an idiomatic interface definition of the target language. Thus, sometimes the target model is referred to in this document as the interlingual definition element model.

[0163] In the examples described herein, the interlingual definition element model is based on a formal grammar that is applied by picker 220 to feature 224 to generate interlingual definition elements for feature 224 for various targets. However, other types of interlingual definition element models are possible. For example, the interlingual definition element model can be machine learning-based, such as, for example, a model trained in a supervised learning manner to generate (infer) interlingual definition elements for feature 224. For example, a separate machine learning model can be trained to make this inference for each possible target. Other possible types of interlingual definition element models may include constraint programming systems, rule-based systems, or expert systems. The techniques do not require a specific type of interlingual definition element model.

[0164] The following (with line numbers) is an exemplary representation of feature 224 extracted by feature extractor 222 from possible interface definitions in general specification 104. The representation can be generated by feature extractor 222 based on tokens parsed from the interface definitions in general specification 104. For purposes of providing a clear example, XML-like notation is used herein to provide this and other examples herein. However, XML or a similar representation is not required for the techniques, and other representations can be used, including, for example, binary data representations or other human and machine-readable representations (e.g., JAVASCRIPT OBJECT NOTATION (JSON)).

[0165]

[0166] In the above example, the representation of feature 224 represents a specific program defined or declared in general specification 104. According to the representation, the program is defined or declared in the "Colors" namespace and the program is named "red?". The program definition declares a formal parameter named "v" of type "Visualizable". The program returns a true value. When invoked at runtime, the implementation of the program (not shown) determines whether the actual parameter of the formal parameter "v" passed in the invocation of "red?" represents red and returns a true value (e.g., a boolean value) reflecting the determination made.

[0167] The target model for the target language (e.g., 226-2) can encompass the formal grammar of the target language that is applied by picker 220 to the representation of feature 224 to generate a set of interlingual definition elements for feature 224 and the target language. For example, consider the following formal grammar (with line numbers) for a possible target language expressed in augmented Backus-Naur form (ABNF) as defined in Request for Comments (RFC) document 5234.

[0168] 00: Start = namespace | toplevels

[0169] 01: namespace = <name space> "namespace" namespaceName "{" toplevels "}"

[0170]

[0171] 02: toplevels = toplevel toplevels | empty

[0172] 03: toplevel = procedure

[0173] 04: procedure = <procedure> type procedureName "(" parameters ")" "{" "..." "}"

[0174]

[0175] 05: parameters = parameter parameters | empty

[0176] 06: parameter = <parameter>type parameterName< / parameter>

[0177] 07: type = <type>typeName< / type>

[0178] 08: namespaceName = <name style = "UpperCamel" partOfSpeech = "nounPhrase" / >

[0179] 09: procedureName = <name style = "LowerCamel" partOfSpeech = "verbPhrase" / >

[0180] 10: parameterName = <name style = "LowerCamel" partOfSpeech = "nounPhrase" / >

[0181] 11: typeName = <name style = "UpperCamel" partOfSpeech = "nounPhrase" / >

[0182] 12: empty =

[0183] The above exemplary grammar produces an XML - based rendering of a set of interlingual definition elements for the input feature 224, which grammar is applied by the picker 220 to the input feature 224. The text that will be produced in the XML output is within double quotes. According to the RFC5234 convention, terms without quotes are non - terminal. The XML tags in the grammar effectively remove those XML tags from the input XML representation of the feature 224 in the XML output. If either has attributes, then output abstract tokens to capture both sets of attributes. This allows name adjustment and reference resolution as described later. For example, the input "<name ref = ″TruthValue″ / >" can be combined with the grammar "<name style = ″UpperCamel″ partOfSpeech = ″nounPhrase″ / >" to produce in the output "<name ref = \″TruthValue\″ style = \″UpperCamel\″ partOfSpeech = \″nounPhrase\″>". Note that the output captures the "ref" attribute of the input as well as the attributes "style" and "partOfSpeech" of the grammar.

[0184] The picker 220 can convert the formal grammar for the target model for the target language into disjunctive normal form. For example, the picker 220 can convert the exemplary formal grammar into conjunctive - disjunctive form. Then, the picker 220 can apply the disjunctive normal form to the representation of the feature 224 to generate a representation of the feature 224 and a set of interlingual definition elements for the target language. For example, the picker 220 can generate the following representation of a set of interlingual definition elements from the above exemplary formal grammar and the above exemplary representation of the feature 224. Here, the representation is expressed as a JAVASCRIPT OBJECT NOTATION (JSON) array. However, such a representation is not required and is only used as an example of a possible representation.

[0185]

[0186] As can be seen from the above examples, the representation of a set of interlingual definition elements incorporates the stylistic conventions of the target language as expressed in an exemplary formal grammar. Such stylistic conventions may include the intermediate capitalization form of the definition elements of the target language, known as camel case. In this example, there are two types of camel case: upper camel case (with the first letter capitalized) and lower camel case (with the first letter in lowercase). In the specific target language of the example, namespace names, return value types, and formal parameter types are conventionally expressed in upper camel case, while program names and formal parameter names are conventionally expressed in lower camel case. The representation of a set of interlingual definition elements allows the picker 220 to generate an idiomatic interface for the target language that follows the stylistic conventions used by the target language programmer community.

[0187] The picker 220 translates a set of interlingual definition elements for the feature 224 and the target language into an idiomatic interface definition for the feature 224 and the target language. For example, given the above exemplary representation of a set of interlingual definition elements, the picker 220 may translate it into the following idiomatic interface definition for a specific target language (e.g., C++).

[0188] 00: namespace Colors{

[0189] 01: bool red(Visualizable& v){...}

[0190] 02:}

[0191] Translation into the target language

[0192] Like human languages, some target languages expect definition elements to be declared in a certain order. For example, English and Mandarin are subject-verb-object, where the subject typically appears before the verb and the verb appears before the object. Other human languages are different. For example, German and Hindi are subject-object-verb. These human languages place the verb last. Another option is that many Celtic and Afro-Asiatic languages are verb-subject-object. In this case, the listener discovers what is being done before discovering who is doing it or to whom.

[0193] Similarly, target programming languages have similar ordering properties that vary between target languages. For example, in the C++ programming language, types come before names (e.g., dentist Alice), but in the TypeScript programming language, names come before types (e.g., Alice dentist). The picker 220 can reorder a set of interlingual definition elements generated for the feature 224 and the target language to match the ordering conventions of the target language. For example, the target model for the target language may contain preferences on how to order features and definition elements, such as, for example, <procedure>inside <returntype>and <parameters>This is illustrated in the above example, where the picker 220 applies an exemplary formal grammar to generate a list of interlingual definition elements, and the order of the elements in the list follows the preference for how the definition elements in the interface definition are sorted in the C++ programming language.

[0194] Alternatively, the picker 220 can present a linear view of a group of interlingual definition elements in any order, which is also referred to herein as an "element bag". The way the picker 220 can provide a linear view of an unordered set of interlingual definition elements generated from the feature 224 for the target language (which is suitable for a conventional interface definition in the target language) is by chaining together simpler inputs. As Figure 4 shown in the UML diagram of, three implementations of the input interface are sufficient to represent the linearized element bag. Instances of the BagOfElements class include a naturally ordered set of interlingual definition elements for the feature 224 and the target language generated by the picker 220 by applying the target model for the target language to the feature 224. Instances of the SerialInput class concatenate a series of input instances rather than text tokens. Thus, instances of the TokenInputAdapter present individual text tokens as an input consisting of one text token. Instances of the BagOElements class not only contain their elements, but also a set of element names provided so far, so that they can provide element values in the requested order without repeating themselves. The followedBy property of the AbstractInput tracks the next Input instance, which is sufficient to answer "what does the next token look like <propertyname>The interface answer of "yes", and its subsequent values of properties with similar names, followed by a closing tag< / propertyname> , and any other elements from the bag that have not been provided yet.”

[0195] Name conflict

[0196] The picker 220 can ensure that the interlingual definition elements generated from the feature 224 for the target language do not conflict with each other. Depending on the target language, the compiler or bytecode verifier for the target language may reject two conflicting elements at a later stage. For example, assume that the picker 220 generates the following target interface in the C++ programming language:

[0197] 00: Color red =...;

[0198] 01: bool red(Visualizable& v){...}

[0199] The C++ compiler will generate a compiler error when compiling the above interface definition because the name "red" is used as both a variable name and a program name. As another example, assume that the picker 220 generates the following target interface in the PYTHON programming language:

[0200] 00: red =...;

[0201] 01: defred(v):...

[0202] In this case, the second "red" definition (at line 01) silently overrides the first "red" definition (at line 00) at runtime, rather than generating a compiler error.

[0203] When generating a set of interlingual definition elements from feature 224 for a target language, the picker 220 may assign distinct names to the elements to avoid name conflicts such as in the example provided above. To this end, when generating the target interface for the target language, the picker 220 may employ at least two different strategies.

[0204] In one strategy, the picker 220 ensures that the names are distinct in situ. Specifically, when generating a set of interlingual definition elements, the picker 220 detects duplicate definitions and adjusts the names of the definitions so that the definitions do not conflict with each other. Figure 5 FIG. 530 is a flowchart of a process performed by the picker 220 to ensure that the names are distinct in situ. At decision 532, the picker 220 determines whether all features 224 have been provided in a set of interlingual definition elements. If so, then the process ends successfully. If not all features 224 have been provided, then at block 534, the picker 220 picks a feature f that has not been provided, designated as f in Figure 5 Next, at block 536, the picker 220 generates a declaration for the unprovided feature f in the set of interlingual definition elements. Next, at block 538, the picker 220 locates any and all declarations for features that have been provided in the set of interlingual definition elements that might conflict with the unprovided feature f. Next, at block 540, the picker 220 adjusts the name of the declaration generated at block 546 or the declaration identified at block 538 to resolve the conflict. At decision 542, if the picker 220 cannot resolve the conflict by the adjustment at block 540, then the process ends with an error. Otherwise, the process returns to block 532 to consider the next unprovided feature, if any. If the general specification 104 has too many similar names and suitable non-arbitrary synonyms cannot be determined, then the picker 220 may not be able to resolve the conflict.

[0205] In the second strategy, after generating a set of interlingual definition elements in the target language for all features 224, picker 220 resolves name conflicts. Specifically, the generated set of interlingual definition elements may contain incomplete definitions with stylistic metadata. Picker 220 may then check the generated elements by name and replace the names to resolve the ambiguity. For example, consider the target interface for the C programming language that provides two procedures: (1) one procedure for determining the absolute value of an integer; and (2) a second procedure for determining the absolute value of a floating-point value. When generating a set of interlingual definition elements for feature 224, picker 220 may generate two procedure definitions with the same tentative name. For example, picker 220 may generate an "abs" procedure for determining the absolute value of an integer and a second "abs" procedure for determining the absolute value of a floating-point value. In this case, picker 220 may add a type indicator to the beginning of the tentative name to resolve the ambiguity. For example, picker 220 may change the tentative name of the first procedure to "iabs" to indicate that the procedure is for determining the absolute value of an integer and change the tentative name of the second procedure to "fabs" to indicate that the procedure is for determining the absolute value of a floating-point value.

[0206] Figure 6 Figure 220 depicts picker 220 implementing the second strategy. Tentative declaration generator 644 generates a preliminary set of interlingual definition elements for the target language from features 224. The preliminary set of interlingual definition elements may encompass declarations with tentative names. After generating a preliminary set of interlingual definition elements for all features 224, the preliminary set of interlingual definition elements may be transmitted to namer 646. Namer 646 may resolve any name conflicts to produce a final set of interlingual definition elements for the target language. Namer 646 may then use the final set of interlingual definition elements to produce the target interface for the target language (e.g., 116-2).

[0207] Some name conflicts may be resolved by picker 220 by adjusting the part of speech. For example, if there is a value corresponding to the color red and a procedure for checking if something is red, and both are tentatively named "red", and the target model for the target language suggests that procedures for answering yes-no questions start with a verb phrase beginning with "is", then the conflict or interference may be resolved by adjusting the procedure name from "red" to "isRed".

[0208] In cases where name conflicts cannot be arbitrarily resolved by picker 220, the programmer or user may be prompted in a computer user interface (e.g., a command line interface or a graphical user interface) to resolve the name conflict. For example, picker 220 may automatically replace a name conflict with a synonym. For example, picker 220 may automatically replace the second occurrence of the conflicting "throw" with "chuck" or "toss". However, such automatic replacement may cause confusion for the programmer. Instead of arbitrarily picking a substitute, picker 220 may employ a last resort conflict avoidance strategy. For example, picker 220 may prompt the user in a computer user interface to enter a different name to resolve the name conflict. For example, instead of selecting "chuck" or "toss" as a substitute for the second occurrence of "throw", the user may select a less casual substitute for the user, such as "throwUp" (as in a call stack) or "throwOut" (as in discarding). In some embodiments, the user's input may be remembered for subsequent occurrences of the same name conflict. For example, the user's input may be stored in a file, a database, etc. Then, when the name conflict subsequently occurs, the user's previous input may be automatically selected as a substitute without prompting the user again.

[0209] Another last resort strategy is to partition conflicting definition pairs into different name spaces. For example, two pairs of name conflicts (beast,beast) and (wickedWitch,wickedWitch) may be partitioned in combination with metadata provided by the user, so as to select the name space names into name space East{beast,wickedWitch} and name space West{beast,wickedWitch}. The name space names provided by the user may be provided by the user in response to a prompt in the computer user interface.

[0210] In addition to avoiding name conflicts in the target language, picker 220 may need to avoid names that have special meanings in the target language, such as reserved keywords. For example, the word "double" has a special meaning in many C-like languages, so using it as the name of a program will cause the compilers of those languages to reject it. The target model for the target language may incorporate a list of boxes or a dictionary that associates disallowed terms with substitutes, such that when generating the target interface for the target language, picker 220 can determine when to look for synonyms or variants of a name.

[0211] Promotion

[0212] Once the name conflicts are resolved by the picker 220, the picker 220 may need to resolve references within a set of interlingual definition elements for the target language. For example, if one of the features 224 defines a type Color and another of the features 224 defines a named constant value RED of type Color, then the second definition may need to reference the first definition in a target language-specific way.

[0213] The picker 220 can generate phrases in the target interface that reliably reference previously defined definition elements. As an example, the picker 220 can generate the following phrase for a definition element that uses the double colon '::' scope resolution operator in the target interface of C++ to explicitly reference a previous definition of type Color:

[0214] 00: Color:: <some defined variable name local to Color>

[0215] As another example, the picker 220 can generate the following phrase for a definition element in the target interface of the JAVA language to explicitly reference a previous definition of type Color:

[0216] 00: com.example.Color

[0217] The picker 220 can also generate "import" and "include" statements in the target interface as needed. For example, some target languages may only allow certain kinds of names to be referenced in combination with other definitions. The picker 220 can generate the source code file for the target interface for the target language, which has the appropriate 'import' and "include" statements. For example, the picker 220 can generate a JAVASCRIPT source code file that has the following statement before any reference to type Color in the source code file:

[0218] 00: import Color from 'color'

[0219] Picker 220 may "hoist" the "import" and "include" statements it generates when translating a set of interlingual definition elements. Hoisting involves moving a sequence of word tokens upward or laterally. One way Picker 220 supports hoisting is by using destination markers in a set of interlingual definition elements for the target language. The destination markers in a set of interlingual definition elements for the target language can be processed by the target-independent hoisting component of Picker 220. Such processing performed by Picker 220 may include moving one or more tokens of a set of elements to an appropriate region of the source code file of the target interface for the target language, where the appropriate region is indicated by the destination marker. After hoisting is complete, the destination marker may be discarded.

[0220] Hoisting is illustrated by Figure 7 an example that depicts source code files in a directory. The source code files define the target interface for the target language generated by Picker 220. In the source code file, Picker 220 has hoisted tokens within the definition of class A to a destination at the start of the file, before the class definition. For example, if the target language is JAVA, the hoisted tokens may encompass a JAVA import phrase (e.g., "import com.example.Color"), and the destination of the hoisted tokens may be after the package declaration and before the class declaration in the file, since a valid JAVA file sequentially contains an optional package declaration, zero or more imports, and zero or more class declarations.

[0221] Source code file

[0222] For efficiency, when loading the target interface generated by Picker 220 for the target language according to the loader of the target language, Picker 220 may limit the number of files and directories that the target programming language has to consider. Picker 220 may require that the definition of the target interface appear in a file named in a certain way. To this end, Picker 220 may group the interlingual definition elements generated by Picker 220 for the target language into file indicators, possibly even including archive file indicators. Picker 220 may store the result of translating a set of interlingual definition elements grouped for a file into that file.

[0223] Merging redundant namespaces

[0224] Picker 220 may merge redundant namespace definitions in a preliminary set of interlingual definition elements generated by Picker 220 for the target language from feature 224. This merging is useful because different target languages have different stylistic conventions around helper programs, such as JAVA static methods, KOTLIN companion object methods or extension functions, PYTHON functions that operate both as methods and as regular functions (receiving "self" as the first parameter).

[0225] Message sending syntax

[0226] The picker 220 can generate a set of interlingual definition elements from the same feature in feature 224 for the target language, where the target language includes the differences between the following:

[0227] · Additional intrinsic programs that programmers expect to be available via the message sending syntax (e.g., infix dot or arrow symbols) and that subtypes can override;

[0228] · Additional extrinsic programs that programmers expect to be available via the message sending syntax but that cannot be overridden by subtypes; and

[0229] · Disassembled programs that do not need to be available via the message sending syntax.

[0230] In this case, the picker 220 can generate a preliminary target interface that translates individual programs in the set of interlingual definition elements into definitions in the preliminary target interface, and the definitions themselves exist in a partial envelope for placing them in context. Then, the picker 220 can perform post-processing operations that merge the contents of identically named envelopes, where the names of the envelopes are derived from the same feature in feature 224. For example, the picker 220 can generate the following preliminary JAVA target interface:

[0231] 00: class C{void f(){...}}

[0232] 01: class C{static void g(){...}}

[0233] The post-processing transfer performed by the picker 220 on the preliminary interface can then merge the contents of the identically named "C" envelopes, as in the following JAVA target interface:

[0234]

[0235] In this case, since they are derived from the same feature in feature 224, the picker 220 can determine that the two classes C in the preliminary target interface are the same class C.

[0236] As another example, for a target language like KOTLIN, the envelopes for the definitions of the above three types may be as follows:

[0237]

[0238] For this example, picker 220 may combine an additional intrinsic example and a second additional extrinsic example into a "class C{}". Additionally, picker 220 may combine any "class C{}" and top-level function definitions from the first additional extrinsic example and the disassembled example into a file related to the type.

[0239] Translation type

[0240] Picker 220 may handle the target language in a way that strictly restricts the types that can be referenced by a program in the target language. For example, the target model for the target language may express that there cannot be multiple names for a type definition. Picker 220 may also adjust the functional elements of the target implementation to use the names assigned by the target interface for the type and have appropriate information hiding directives. For example, picker 220 may call a per-target language quote or plugin of custom programming to adjust the compiler output (e.g., adjust the target implementation of the target language).

[0241] Picker 220 may handle the differences between target languages that specify variance of generic type parameters. Generally, such variance is specified in two different places: (1) in the definition of a generic type (e.g., as in SCALA OR KOTLIN); or (2) in the use of a generic type (e.g., as in JAVA). To handle this, picker 220 may generate interlingual definition elements for both the generic type form and the generic type actual to both contain variance information. Then, when translating a set of interlingual definition elements into the target interface of a target language, depending on the requirements for specifying variance of generic type parameters in the target language, picker 220 may ignore one and support the other.

[0242] Basic computing device

[0243] The techniques described herein can be implemented by at least one computing device. If implemented by more than one computing device, the techniques can be implemented in whole or in part using a combination of computing devices coupled together by a network such as a packet data network. The computing devices used in the implementation of the techniques can be hardwired to perform some or all of the techniques, or can include digital electronic devices such as at least one application specific integrated circuit (ASIC) or field programmable gate array (FPGA) that are persistently programmed to perform some or all of the techniques, or can include at least one general purpose hardware processor programmed to perform some or all of the techniques in program instructions in firmware, memory, other storage devices, or a combination thereof. The computing devices used in the implementation of the techniques can also combine custom hardwired logic, ASICs, or FPGAs with custom programming to accomplish some or all of the techniques. The computing devices used in the implementation of the techniques can be server computing devices, workstation computing devices, personal computing devices, portable computing devices, handheld computing devices, mobile computing devices, or any other computing device incorporating hardwired or program logic to perform some or all of the techniques.

[0244] Figure 8 is a block diagram of an exemplary basic computing device that can be used in an implementation of the techniques. In Figure 8 the example of, computing device 800 and instructions for implementing some or all of the techniques in hardware, software, or a combination of hardware and software are schematically represented as, for example, boxes and circles with the same level of detail that a person of ordinary skill in the art to which the present disclosure pertains would typically use to convey details about computer architectures and computing device implementations.

[0245] Computing device 800 includes an input / output (I / O) subsystem 802 that can include a bus or other communication mechanism for conveying information or instructions between components of computing device 800 via an electronic signal path. I / O subsystem 802 can include an I / O controller, a memory controller, and at least one I / O port. The electronic signal paths are schematically represented in the figures as, for example, lines, one-way arrows, or two-way arrows.

[0246] At least one hardware processor 804 is coupled to I / O subsystem 802 for processing information and instructions. Hardware processor 804 can include, for example, a general purpose microprocessor or microcontroller or a special purpose microprocessor such as an embedded system or a graphics processing unit (GPU) or a digital signal processor or an ARM processor. Processor 804 can include an integrated arithmetic logic unit (ALU) or can be coupled to a separate ALU.

[0247] The computing device 800 includes one or more memory units 806, such as a main memory, which is coupled to the I / O subsystem 802 for electronically storing data and instructions to be executed by the processor 804. The memory 806 may include volatile memory, such as various forms of random access memory (RAM) or other dynamic storage devices. The memory 806 may also be used to store temporary variables or other intermediate information during the execution of instructions by the processor 804. When stored in a non-transitory storage medium accessible by the processor 804, such instructions may cause the computing device 800 to be a special-purpose machine, the special-purpose machine being customized to perform the operations specified in the instructions.

[0248] The computing device 800 also includes non-volatile memory coupled to the I / O subsystem 802, such as read-only memory (ROM) 808 or other static storage devices, for storing information and instructions for the processor 804. The ROM 808 may include various forms of programmable ROM (PROM), such as erasable PROM (EPROM) or electrically erasable PROM (EEPROM). The permanent storage device unit 810 may include various forms of non-volatile RAM (NVRAM), such as FLASH memory or solid-state storage devices, magnetic disks or optical disks such as CD-ROM or DVD-ROM, and may be coupled to the I / O subsystem 802 to store information and instructions. The storage device 810 is an example of a non-transitory computer-readable medium that can be used to store instructions and data, which, when executed by the processor 804, cause a computer-implemented method to perform some or all of the techniques.

[0249] Instructions in the memory 806, ROM 808, or storage device 810 may include one or more sets of instructions that are organized as modules, methods, objects, functions, routines, or invocations. The instructions may be organized as one or more computer programs, operating system services, or applications including mobile apps. The instructions may include an operating system or system software; one or more libraries that support multimedia, programming, or other functions; data protocol instructions or stacks that implement TCP / IP, HTTP, or other communication protocols; file processing instructions that interpret and render files encoded using HTML, XML, JPEG, MPEG, or PNG; user interface instructions that render or interpret commands for a graphical user interface (GUI), command line interface, or text user interface; application software, such as an office suite, Internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games, or various applications. The instructions may implement a web server, web application server, or web client. The instructions may be organized into a presentation layer, application layer, and data storage layer, such as a relational database system using Structured Query Language (SQL) or NoSQL, an object store, a graph database, a flat file system, or other data storage devices.

[0250] The computing device 800 may be coupled to at least one output device 812 via the I / O subsystem 802. The output device 812 may be a digital computer display. Examples of displays that may be used include a touch screen display, a light emitting diode (LED) display, a liquid crystal display (LCD), or an electronic paper display. The computing device 800 may include other types of output devices 812 as an alternative or supplement to the display device. Examples of other output devices 812 include printers, ticket printers, plotters, projectors, sound cards or video cards, speakers, buzzers, or piezoelectric devices or other audible devices, lights, or LED or LCD indicators, haptic devices, actuators, or servo mechanisms.

[0251] The input device 814 may be coupled to the I / O subsystem 802 for passing signals, data, command selections, or gestures to the processor 804. Examples of the input device 814 include a touch screen, a microphone, a still and video digital camera, alphanumeric keys and other keys, a keypad, a keyboard, a graphics tablet, an image scanner, a joystick, a clock, a switch, a button, a dial, a slider, or various types of sensors, such as force sensors, motion sensors, thermal sensors, accelerometers, gyroscopes, and inertial measurement unit (IMU) sensors, or various types of transceivers, such as wireless transceivers, such as cellular or Wi-Fi, radio frequency (RF), or infrared (IR) transceivers, and global positioning system (GPS) transceivers.

[0252] Another type of input device is the control device 816, which can perform cursor control or other automatic control functions, such as navigating in a graphical interface on a display screen, as an alternative or supplement to the input function. The control device 816 can be a touchpad, a mouse, a trackball, or cursor direction keys, for passing direction information and command selections to the processor 804 and for controlling the movement of the cursor on the display 812. The input device can have at least two degrees of freedom on two axes (a first axis (e.g., x) and a second axis (e.g., y)), which allows the device to specify a position in a plane. Another type of input device is a wired, wireless, or optical control device, such as a joystick, a wand, a console, a steering wheel, pedals, a shift mechanism, or other types of control devices. The input device 814 can include a combination of multiple different input devices, such as a camera and a depth sensor.

[0253] The computing device 800 can include an Internet of Things (IoT) device or other computing appliance in which one or more of the output device 812, the input device 814, and the control device 816 are omitted. The input device 814 can include one or more cameras, motion detectors, thermometers, microphones, seismic detectors, other sensors or detectors, measurement devices, or encoders, and the output device 812 can include a special-purpose display, such as a single-line LED or LCD display, one or more indicators, a display panel, a meter, a valve, a solenoid, an actuator, or a servo mechanism.

[0254] When the computing device 800 is a mobile or portable computing device, the input device 814 can include a Global Positioning System (GPS) receiver coupled to a GPS module that is capable of triangulating multiple GPS satellites to determine and generate geographic location or position data, such as latitude and longitude values of the geophysical location of the computing device 800. The output device 812 can include hardware, software, firmware, and interfaces for generating a location report packet, notification, pulse, or heartbeat signal directed to the host 824 or the server 830, or other periodic data transmissions that specify the location of the computing device 800, either alone or in combination with other dedicated data.

[0255] The computing device 800 can implement some or all of the techniques using custom hardwired logic, at least one ASIC or FPGA, firmware, or program instructions or logic that, when loaded and used or executed in combination with the computing device 800, cause the computing device 800 to operate or be programmed to operate as a special-purpose machine.

[0256] Techniques performed by computing device 800 may be performed in response to execution of at least one sequence of at least one instruction contained in main memory 806 by processor 804. Such instructions may be read into main memory 806 from another storage medium, such as storage device 810. Execution of the instruction sequence contained in main memory 806 causes processor 804 to perform some or all of the techniques. Hardwired circuitry may be used in place of or in combination with software instructions.

[0257] The term "storage medium" as used herein refers to any non-transitory computer-readable medium that stores data or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media or volatile media. For example, non-volatile media includes optical or magnetic disks, such as storage device 810. Volatile media includes dynamic memory, such as memory 806. Common forms of storage media include, for example, hard disks, solid state drives, flash drives, magnetic data storage media, any optical or physical data storage media, memory chips, and the like.

[0258] Storage media is distinct from transmission media but may be used in conjunction with transmission media. Transmission media participates in the transfer of information between storage media. For example, transmission media includes coaxial cables, copper wire, and fiber optics, including the wires that comprise a bus including I / O subsystem 802. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0259] Various forms of media may be involved in carrying at least one sequence of at least one instruction to processor 804 for execution. For example, the instructions may initially be carried by a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions using a modem over a communication link such as a fiber optic cable, coaxial cable, or telephone line. A modem or router local to computing device 800 may receive the data on the communication link and translate the data for reading by computing device 800. For example, a receiver, such as a radio frequency antenna or infrared detector, may receive data carried in a wireless or optical signal, and appropriate circuitry may provide the data to I / O subsystem 802, such as placing the data on a bus. I / O subsystem 802 carries the data to memory 806, and processor 804 retrieves and executes the instructions from memory 806. Instructions received by memory 806 may optionally be stored on storage device 810 before or after execution by processor 804.

[0260] The computing device 800 also includes a communication interface 818 coupled to the bus 802. The communication interface 818 provides two-way data communication coupled to a network link 820, which is directly or indirectly connected to at least one communication network, such as a public or private cloud on network 822 or the Internet. For example, the communication interface 818 can be an Ethernet networking interface, an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem to provide a data communication connection to a corresponding type of communication line, such as an Ethernet cable or any kind of metallic cable or fiber optic line or telephone line. The network 822 broadly represents a local area network (LAN), a wide area network (WAN), a campus network, the Internet, or any combination thereof. The communication interface 818 can include a LAN card to provide a data communication connection to a compatible LAN, or a cellular wireless telephone interface wired to send or receive cellular data according to a cellular wireless telephone network standard, or a satellite radio interface wired to send or receive digital data according to a satellite wireless network standard. In any such implementation, the communication interface 618 sends and receives electrical, electromagnetic, or optical signals through a signal path that carries a digital data stream representing various types of information.

[0261] The network link 820 generally uses, for example, satellite, cellular, Wi-Fi, or Bluetooth technology to provide electrical, electromagnetic, or optical data communication directly or through at least one network to other data devices. For example, the network link 820 can provide a connection to a host computer 824 through the network 822.

[0262] In addition, the network link 820 can provide a connection through the network 822, or a connection to other computing devices via an interconnection device and / or computer operated by an Internet service provider (ISP) 826. The ISP 826 provides data communication services through a global packet data communication network represented as the Internet 828. A server computer 830 can be coupled to the Internet 828. The server 830 broadly represents any computer, data center, virtual machine, or virtual computing instance with or without a hypervisor, or a computer that executes a containerized program system such as DOCKER or KUBERNETES. The server 830 can represent an electronic digital service implemented using more than one computer or instance and accessed and used by transmitting web service requests, a uniform resource locator (URL) string with parameters in an HTTP payload, an API invocation, an app service invocation, or other service invocations.

[0263] The computing device 800 and the server 830 can form elements of a distributed computing system that includes other computers, processing clusters, server farms, or other organizations of computers that cooperate to perform tasks or execute applications or services. The server 630 can include one or more sets of instructions organized as modules, methods, objects, functions, routines, or invocations. The instructions can be organized as one or more computer programs, operating system services, or applications including mobile apps. The instructions can include an operating system and / or system software; one or more libraries that support multimedia, programming, or other functions; data protocol instructions or stacks that implement TCP / IP, HTTP, or other communication protocols; file format processing instructions that interpret or render files encoded using HTML, XML, JPEG, MPEG, or PNG; user interface instructions that render or interpret commands for a graphical user interface (GUI), command line interface, or text user interface; application software such as office suites, Internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games, or various applications. The server 830 can include a web application server that hosts a presentation layer, an application layer, and a data storage layer, such as a relational database system using Structured Query Language (SQL) or NoSQL, an object store, a graph database, a flat file system, or other data storage devices.

[0264] The computing device 800 can send messages and receive data and instructions, including program code, via a network, network link 820, and communication interface 818. In an Internet example, the server 830 can transmit request code for an application program via the Internet 828, ISP 826, local network 822, and communication interface 818. The received code can be executed by the processor 804 when it is received, or stored in the storage device 810 or other non-volatile storage device for later execution.

[0265] Basic Software System

[0266] Figure 9 is a block diagram of an exemplary basic software system 900 that can be used to control Figure 8 the operation of the computing device 800. The software system 900 and its components including its connections, relationships, and functions are meant to be examples only and are not meant to limit the implementations of the technology. Other software systems suitable for implementing the technology can have different components, including components with different connections, relationships, and functions.

[0267] The software system 900 is provided to bootstrap the operation of the computer system 800. The software system 900 includes a kernel or operating system (OS) 910 that can be stored in the system memory (RAM) 806 and on a fixed storage device (e.g., hard disk or flash memory) 810.

[0268] The OS 910 manages the low-level aspects of computer operation, including managing the execution of processes represented as 902-1, 902-2, 902-3, …, 902-N, memory allocation, file input and output (I / O), and device I / O. One or more applications can be "loaded" (e.g., transferred from the fixed storage device 810 to the memory 806) to be executed by the system 900 as one or more processes. Applications or other software intended for use on the computing device 800 can also be stored as a set of downloadable computer-executable instructions, e.g., for downloading and installation from an Internet location (e.g., a web server, an app store, or other online service).

[0269] The execution of application program instructions can implement a process (e.g., 902-2) in the form of an instance of a computer program that is being executed and consists of the program code and its current activities. Depending on the operating system (OS), a process (e.g., 902-3) can consist of multiple execution threads that execute instructions concurrently. In this context, a computer program is a passive collection of instructions, while a process (e.g., 902-1) can be the actual execution of those instructions. Several processes (e.g., 902-1 and 902-2) can be associated with the same program; for example, starting several instances of the same program generally means that more than one process is being executed, or a program that is initially started as a single process may subsequently spawn (e.g., fork) additional processes.

[0270] The OS 910 can implement multitasking to allow the processes 902-1, 902-2, 902-3, …, 902-N to share the processor 804. Although each processor 804 or core of a processor executes a single task at a time, the computing device 800 can be programmed to implement multitasking to allow each processor to switch between the tasks being executed without having to wait for each task to complete. The switch can be performed when a task performs an input / output operation, when the task indicates that it can be switched, or when it is interrupted by hardware. By performing rapid context switches to give the appearance of multiple processes executing in parallel simultaneously, time sharing can be implemented to allow for rapid response of interactive user applications. For security and reliability, the OS 910 can prevent direct communication between independent processes, thus providing a strictly mediated and controlled inter-process communication function.

[0271] In some instances, processes 902-1, 902-2, 902-3, …, 902-N and the application programs they implement may be executed within application container 940. An application container is generally an operating mode of OS 910, in which OS 910 allows multiple isolated user space instances to run on OS 910. Application container 940 is an example of such an instance. Alternatively, an instance itself is sometimes also referred to as a zone, virtual private server, partition, virtual environment, virtual kernel, or jail. An application container provides a mechanism by which limited hardware computing resources, such as CPU time and storage media space, can be allocated among the instances.

[0272] Software system 900 includes a graphical user interface (GUI) 915 for receiving user commands and data graphically (e.g., "clicking" or "touch gestures"). These inputs can in turn cause the system 900 to perform actions according to instructions from operating system 910 or processes 902-1, 902-2, 902-3, …, 902-N. GUI 915 is also used to display the operation results from OS 910 and processes 902-1, 902-2, 902-3, …, 902-N 902, whereby the user can provide additional input or terminate the session (e.g., log off).

[0273] OS 910 may be executed directly on the bare hardware 920 (e.g., processor 804) of computing device 800. Alternatively, a hypervisor or virtual machine monitor (VMM) 930 may be interposed between the bare hardware 920 and OS 910. In this configuration, VMM 930 acts as a software "buffer" or virtualization layer between OS 910 and the bare hardware 920 of computing device 800.

[0274] VMM 930 instantiates and runs one or more virtual machine instances ("guest machines"). Each guest machine includes a "guest" operating system such as OS 910, and one or more applications designed to execute on the guest operating system, such as application 902. VMM 930 provides a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0275] In some instances, VMM 930 may allow the guest operating system to run as if it were running directly on the bare hardware 920 of computing device 800. In these instances, the same version of the guest operating system configured to execute directly on the bare hardware 920 can also execute on VMM 930 without modification or reconfiguration. In other words, in some instances, VMM 930 can provide full hardware and CPU virtualization to the guest operating system.

[0276] In other instances, the guest operating system may be specifically designed or configured to execute on the VMM 930. In these instances, the guest operating system is "aware" that it is executing on the virtual machine monitor. In other words, in some instances, the VMM 930 may provide para-virtualization to the guest operating system.

[0277] Cloud computing

[0278] The techniques described herein may be implemented in a "cloud computing" environment. The term "cloud computing" is generally used herein to describe a computing model that enables on-demand access to a shared pool of computing resources such as computer networks, servers, software applications, and services, and allows for the rapid provisioning and release of resources with minimal management effort or service provider interaction.

[0279] Cloud computing environments (sometimes referred to as cloud environments or the cloud) may be implemented in a variety of different ways to best meet different requirements. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the general public. In contrast, a private cloud environment is generally only used by or within a single organization. Community clouds are intended to be shared by several organizations within a community; and hybrid clouds include two or more types of clouds (e.g., private, community, or public) that are bound together by data and application portability.

[0280] Generally speaking, the cloud computing model enables some of those responsibilities that may previously have been provided by an organization's own information technology department to be delivered as service layers within the cloud environment for consumption by consumers (either within or outside the organization, depending on the public / private nature of the cloud). Depending on the particular implementation, the precise definition of the components or features provided by or within each cloud service layer may vary, but common examples include: Software as a Service (SaaS), where the consumer uses software applications running on the cloud infrastructure, and the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), where the consumer can use software programming languages and development tools supported by the PaaS provider to develop, deploy, and control its own applications, and the PaaS provider manages or controls other aspects of the cloud environment (e.g., everything under the runtime execution environment). Infrastructure as a Service (IaaS), where the consumer can deploy and run any software applications, and / or configure processing, storage devices, networks, and other underlying computing resources, and the IaaS provider manages or controls the underlying physical cloud infrastructure (e.g., everything below the operating system layer). Database as a Service (DBaaS), where the consumer uses a database server or database management system running on the cloud infrastructure, and the DbaaS provider manages or controls the underlying cloud infrastructure, applications, and servers, including one or more database servers.

[0281] Other aspects of the present disclosure

[0282] Unless the context clearly indicates otherwise, the term "or" is used in the foregoing specification and the appended claims in its inclusive sense (and not in its exclusive sense), so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list.

[0283] Unless the context clearly indicates otherwise, the terms "comprising," "including," "having," "based on," "comprising of," and the like are used in an open-ended manner in the foregoing specification and the appended claims and do not exclude additional elements, features, acts, or operations.

[0284] Unless the context clearly indicates otherwise, conjunctive language such as the phrase "at least one of X, Y, and Z" should be understood to convey that an article, item, etc. can be X, Y, or Z, or a combination thereof. Thus, such conjunctive language is not intended to defaultly require the presence of at least one of X, at least one of Y, and at least one of Z each.

[0285] Unless the context clearly indicates otherwise, as used in the foregoing detailed description and the appended claims, the singular forms "a," "an," and "the" are also intended to include the plural forms.

[0286] Unless the context clearly indicates otherwise, in the foregoing detailed description and the appended claims, although the terms first, second, etc. are used in some instances herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first computing device may be referred to as a second computing device, and similarly, a second computing device may be referred to as a first computing device. The first computing device and the second computing device are both computing devices, but they are not the same computing device.

[0287] In the foregoing specification, these techniques have been described with reference to numerous specific details, which may vary according to different embodiments. Therefore, the specification and the drawings are to be regarded in an illustrative rather than a restrictive sense.< / parameters> < / returntype> < / procedure>

Claims

1. A method for deriving idiomatic interfaces for multiple target computer programming languages from a common specification of a library, the method comprising: obtaining a set of features extracted from the common specification, wherein each feature in the set of features includes one or more lexical tokens extracted from the common specification, and the one or more lexical tokens form a syntactically permissible construct in a source programming language; and for each target computer programming language of the multiple target computer programming languages, applying an interlingual definition element model for the target computer programming language to the set of features to generate a set of interlingual definition elements for the set of features and the target computer programming language, and translating the set of interlingual definition elements for the set of features and the target computer programming language into an idiomatic interface definition for the set of features in the target computer programming language, wherein, for each target computer programming language of the multiple target computer programming languages, the interlingual definition element model for the target computer programming language uses a formal grammar of the target computer programming language to represent how the target computer programming language expresses definition elements in an idiomatic interface definition in the target computer programming language, and wherein the applying the interlingual definition element model for the target computer programming language to the set of features to generate the set of interlingual definition elements for the set of features and the target computer programming language is based on applying the formal grammar of the target computer programming language to the set of features to generate the set of interlingual definition elements for the set of features and the target computer programming language.

2. The method according to claim 1, further comprising: for each target computer programming language of the multiple target computer programming languages, compiling the common specification into an implementation in the target computer programming language, and connecting the idiomatic interface definition for the set of features in the target computer programming language to the implementation in the target computer programming language to form a library in the target computer programming language.

3. The method according to claim 1, wherein at least one of the multiple target computer programming languages is object-oriented, and wherein at least one of the multiple target computer programming languages is not object-oriented.

4. The method according to claim 1, further comprising: for each target computer programming language of the multiple target computer programming languages, translating the set of interlingual definition elements for the set of features and the target computer programming language into the idiomatic interface definition for the set of features and the target computer programming language based on providing a linearized view of the set of interlingual definition elements for the set of features and the target computer programming language.

5. The method according to claim 1, further comprising: for at least one of the multiple target computer programming languages: Detect a name conflict between a first feature and a second feature in the set of features; and Adjust the name of the first feature to resolve the name conflict; and wherein the idiomatic interface definition for the set of features and the at least one target computer programming language includes the name-adjusted first feature.

6. The method according to claim 1, wherein, for each target computer programming language of the plurality of target computer programming languages, translating the set of interlingual definition elements for the set of features and the target computer programming language into the idiomatic interface definition for the set of features and the target computer programming language is based on: translating the set of interlingual definition elements for the set of features and the target computer programming language into a tentative interface definition for the set of features and the target computer programming language, and deriving the idiomatic interface definition for the set of features and the target computer programming language from the tentative interface definition for the set of features and the target computer programming language based on detecting and resolving any name conflicts in the tentative interface definition for the set of features and the target computer programming language.

7. The method according to claim 1, further comprising: for at least one target computer programming language of the plurality of target computer programming languages: detect a name conflict between a first feature and a second feature in the set of features; adjust the name of the first feature from a noun phrase to a verb phrase to resolve the name conflict; and wherein the idiomatic interface definition for the set of features and the at least one target computer programming language includes the name-adjusted first feature.

8. The method according to claim 1, further comprising: for at least one target computer programming language of the plurality of target computer programming languages: detect a name conflict between a first feature and a second feature in the set of features; prompt for user input to resolve the name conflict; receive user input to adjust the name of the first feature; and and wherein the idiomatic interface definition for the set of features and the at least one target computer programming language includes the name-adjusted first feature.

9. The method according to claim 1, further comprising: for at least one target computer programming language of the plurality of target computer programming languages: detect a first name conflict between a first feature and a second feature in the set of features; detect a second name conflict between a third feature and a fourth feature in the set of features; and wherein the idiomatic interface definition for the set of features and the at least one target computer programming language resolves the first name conflict and the second name conflict by bounding the first feature and the third feature in a first namespace and bounding the second feature and the fourth feature in a second namespace.

10. The method according to claim 1, further comprising: For at least one target computer programming language of the plurality of target computer programming languages, detect that a first feature of the set of features uses a reserved name in the at least one target computer programming language; and perform name adjustment on the first feature to avoid the reserved name; and wherein the idiomatic interface definition for the set of features and the at least one target computer programming language includes the name-adjusted first feature.

11. The method according to claim 1, wherein, for at least one target computer programming language of the plurality of target computer programming languages, the translating of the set of interlingual definition elements for the set of features and the at least one target computer programming language into the idiomatic interface definition for the set of features and the at least one target computer programming language is based on promoting one or more token sequences of the set of features in the idiomatic interface definition for the set of features and the at least one target computer programming language.

12. A non-transitory storage medium storing instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform a method for deriving idiomatic interfaces for at least eight target computer programming languages from a general specification of a library, the method comprising: obtaining a set of features extracted from the general specification, wherein each feature in the set of features includes one or more lexical tokens extracted from the general specification, and the one or more lexical tokens form a syntactically permissible construct in a source programming language; and for each target computer programming language of the at least eight target computer programming languages, applying an interlingual definition element model for the target computer programming language to the set of features to generate a set of interlingual definition elements for the set of features and the target computer programming language, and translating the set of interlingual definition elements for the set of features and the target computer programming language into an idiomatic interface definition for the set of features in the target computer programming language, wherein, for each target computer programming language of the at least eight target computer programming languages, the interlingual definition element model for the target computer programming language uses a formal grammar of the target computer programming language to represent how the target computer programming language expresses definition elements in an idiomatic interface definition in the target computer programming language, and wherein the applying of the interlingual definition element model for the target computer programming language to the set of features to generate the set of interlingual definition elements for the set of features and the target computer programming language is based on applying the formal grammar of the target computer programming language to the set of features to generate the set of interlingual definition elements for the set of features and the target computer programming language.

13. The non-transitory storage medium according to claim 12, wherein the method further comprises: For each of the at least eight target computer programming languages, compile the general specification into an implementation in the target computer programming language and connect the idiomatic interface definition for the set of features in the target computer programming language to the implementation in the target computer programming language to form a library in the target computer programming language.

14. The non-transitory storage medium according to claim 12, wherein the method further comprises: For each of the at least eight target computer programming languages, based on providing a linearized view of the set of interlingual definition elements for the set of features and the target computer programming language, translate the set of interlingual definition elements for the set of features and the target computer programming language into the idiomatic interface definition for the set of features and the target computer programming language.

15. The non-transitory storage medium according to claim 12, wherein, for each of the at least eight target computer programming languages, translating the set of interlingual definition elements for the set of features and the target computer programming language into the idiomatic interface definition for the set of features and the target computer programming language is based on: translating the set of interlingual definition elements for the set of features and the target computer programming language into a tentative interface definition for the set of features and the target computer programming language, and deriving the idiomatic interface definition for the set of features and the target computer programming language from the tentative interface definition for the set of features and the target computer programming language based on detecting and resolving any name conflicts in the tentative interface definition for the set of features and the target computer programming language.

16. A computing system for deriving idiomatic interfaces for multiple target computer programming languages from a general specification of a library, the computing system comprises: one or more processors; a storage medium; and instructions stored in the storage medium and which when executed by the one or more processors cause the computing system to perform the following steps: Obtain a set of features extracted from the general specification, wherein each feature in the set of features comprises one or more token ordinals extracted from the general specification, the one or more token ordinals forming a syntactically permissible construct in a source programming language; and for each of the multiple target computer programming languages, apply an interlingual definition element model for the target computer programming language to the set of features to generate a set of interlingual definition elements for the set of features and the target computer programming language, and translate the set of interlingual definition elements for the set of features and the target computer programming language into an idiomatic interface definition for the set of features in the target computer programming language, Among them, for each of the multiple target computer programming languages, the interlingual definition element model for the target computer programming language uses the formal grammar of the target computer programming language to represent how the target computer programming language expresses definition elements in the idiomatic interface definition in the target computer programming language, and wherein applying the interlingual definition element model for the target computer programming language to the set of features to generate the set of interlingual definition elements for the set of features and the target computer programming language is based on applying the formal grammar of the target computer programming language to the set of features to generate the set of interlingual definition elements for the set of features and the target computer programming language.

17. The computing system according to claim 16, further comprising instructions stored in the storage medium, the instructions when executed by the one or more processors cause the computing system to perform the following steps: For each of the multiple target computer programming languages, compile the general specification into an implementation in the target computer programming language, and connect the idiomatic interface definition for the set of features in the target computer programming language to the implementation in the target computer programming language to form a library in the target computer programming language.

Images