WO2002039647A2 - A multi-language execution method - Google Patents

A multi-language execution method Download PDF

Info

Publication number
WO2002039647A2
WO2002039647A2 PCT/US2001/046928 US0146928W WO0239647A2 WO 2002039647 A2 WO2002039647 A2 WO 2002039647A2 US 0146928 W US0146928 W US 0146928W WO 0239647 A2 WO0239647 A2 WO 0239647A2
Authority
WO
WIPO (PCT)
Prior art keywords
code
language
programming language
section
statements
Prior art date
Application number
PCT/US2001/046928
Other languages
French (fr)
Other versions
WO2002039647A3 (en
Inventor
Adam Bosworth
David Bau, Iii
John C. Schneider
Original Assignee
Bea Systems, Incorporated
Vasilik, Kenneth, Eric
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bea Systems, Incorporated, Vasilik, Kenneth, Eric filed Critical Bea Systems, Incorporated
Priority to AU2002220243A priority Critical patent/AU2002220243A1/en
Priority to US10/089,139 priority patent/US8156471B2/en
Publication of WO2002039647A2 publication Critical patent/WO2002039647A2/en
Publication of WO2002039647A3 publication Critical patent/WO2002039647A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/31Programming languages or programming paradigms

Definitions

  • the present invention relates to the field of data processing. More specifically, the present invention relates to the employment of multiple programming languages interleaved within a single source file for data processing operations.
  • Each programming language has its strength and weakness, and is often suitable for certain applications over other applications. It is often desirable to be able to employ instructions or statements of different programming languages to solve a problem or implement an application. However, few programming languages offer such support. To the extent that mixed language execution is supported, the approach is often proprietary and not extendable to other programming languages. Thus, an improved mixed multi-language method, especially, one that is extensible to multiple programming languages is desired.
  • a data processing representation is expressed in the form of code sections, which may be nested, using multiple programming languages.
  • the representation is read by an execution engine.
  • the execution engine identifies the programming language of each code section, and a corresponding language specific processing unit is invoked to process the code section.
  • the language specific processing unit reads that section of the representation, identifying sub-sections specified in it's associated language and other subsections specified in unknown languages. It executes the sub-sections specified in its associated language with the intended semantics and in the appropriate order. When a sub-section specified in an unknown language is encountered, it delegates processing of that sub-section back to the execution engine, which repeats this process for the unknown sub-section.
  • the execution engine coordinates execution of the unknown sub-section, using one or more appropriate language specific processing units, and returns the result back to the requesting language specific processor, which will continue processing where it left off.
  • a header section comprising directive and/or declarative statement is also supported for one or more of the languages.
  • the corresponding language specific processing unit imports data packages enumerated by the directive statement, as directed, or instantiate methods/variables enumerated by the declarative statement, for code sections of the language, as declared.
  • the mixed usage of at least three programming languages is supported. The first language is an XML-like declarative language, the second language is the Java language and the third language is XML.
  • FIG 1 illustrates an overview of the multi-language execution method of the present invention, in accordance with one embodiment
  • Figure 2a illustrates the relevant operational flow of the execution, engine of Fig. 1, in accordance with one embodiment
  • Figure 2b illustrates the relevant operational flow of a language specific processing unit of Fig. 1, for processing a code section of the language, in accordance with one embodiment
  • Figure 2c illustrates the relevant operational flow of a language specific processing unit of Fig. 1, for processing a header section of the language, in accordance with one embodiment
  • FIG. 3 illustrates a computer system suitable for use to practice the present invention, in accordance with one embodiment
  • Figure 4 illustrates a multi-language data processing representation of Fig. 1 , in further detail in accordance with one embodiment.
  • the present invention includes a method for specifying data processing operations using programming instructions of multiple programming languages, and for executing the multi-language data processing representation.
  • a computing environment 102 is provided with an execution engine 104, supplemented with a number of language specific processing units 105, to facilitate execution of data processing representations 106 expressed with programming instructions of multiple programming languages.
  • execution engine 104 supplemented with a number of language specific processing units 105, to facilitate execution of data processing representations 106 expressed with programming instructions of multiple programming languages.
  • computing environment 102 is also provided with function libraries 112 of the programming languages.
  • a multi-language data processing representation 106 includes one or more language namespace declarations 108 declaring language or languages employed, and one or more code sections 110 of the declared languages. In other embodiments, other non-namespace means may also be employed to declare the languages involved. As will be described in more detail below, each code section 110 may include sub-sections written in one or more other languages, that is code sections 110 of the different programming languages may be interleaved. Each sub-section may in turn have sub-sub-sections written in other languages, and so forth.
  • data processing representation 106 may also include one or more language specific header sections 109 specifying various "preliminary" matters for subsequent code sections 110 of the language.
  • Execution engine 104 is endowed with logic to anticipate that data processing representations 106 may include code sections of different programming languages, and with the assistance of language specific processing units 105 be able to handle and facilitate execution of these code sections of different programming languages. Moreover, execution engine 104 is endowed with logic to anticipate and handle inter-mixing of code sections of the different programming languages. For the embodiment, upon encountering a code section/statement of a language, execution engine 104 invokes the corresponding language specific processing unit 105 to augment and provide the language specific processing required to process and facilitate execution of the code section/statement.
  • Language specific processing units 105 are endowed with logic to identify sub-sections written in unknown programming languages, and delegate the processing of those sub-sections back to the execution engine 104.
  • the execution engine 104 will pass the sub-section to an appropriate language specific processor and return the result to the requesting language specific processing unit 105.
  • execution engine 104 and language specific processing units are endowed with logic to identify sub-sections written in unknown programming languages, and delegate the processing of those sub-sections back to the execution engine 104.
  • the execution engine 104 will pass the sub-section to an appropriate language specific processor and return the result to the requesting language specific processing unit 105.
  • data processing representations 106 are intended to represent a broad range of data processing representation methodologies known in the art, and execution engine 104 is intended to represent a broad range of the corresponding engines in support of these methodologies.
  • computing environment 102 may be disposed in a single or multi-processor system, or a collection of networked systems. In the case of networked systems, the systems may be networked locally, or across a number of private and/or public networks, including the Internet.
  • FIG. 4 a block diagram illustrating a mixed language data process representation 106 of Fig. 1 in further details, in accordance with one embodiment is shown. As illustrated, and described
  • data processing representation 106 includes one or more language namespace declarations 108 declaring one or more languages employed.
  • declarations 108 are expressed in accordance with the following exemplary syntax:
  • xl://crossgain.net/lang/xsheet/ is a namespace using a specially formed URI identifying one language that may be used in this source.
  • the execution engine uses this URI to locate an appropriate language specific processing unit for sections written in this language.
  • "xl://crossgain.net/lang/java/” is a specially formed URI identifying a second language that may be used in this source (an extension of the well known Java language in this example).
  • the execution engine uses this URI to locate an appropriate language specific processing unit for sections written in this language.
  • xs is a namespace prefix used to identify sections of the source written in the language identified by the associated namespace, "xl://crossgain.net/lang/xsheet/"
  • data processing representation 106 further includes a number of language specific header sections 109 of selected supported languages.
  • each header section 109 may include one or more directive statements 402 directing one or more preliminary or preparatory actions, such as importing of data packages, to be performed, and one or more declarative statements 404 declaring one or more processing methods or instance variables to be instantiated for use by subsequent code sections 110 of the language.
  • a header section 109 may be declared in accordance with the following exemplary syntax:
  • the above example directive directs the import of W3C's definition of the document object model for use by subsequent Java code sections.
  • data processing section 106 further includes language specific as well as mixed language code sections 110a and 110b.
  • statements of a second language may be intermixed among statement of a first language, employing one or more sets of delimiting language tag pairs 442a-442b and 444a-444b as shown.
  • the Java specific processing unit asks the execution engine to evaluate the xsheet code 10 times. Each time, the results returned by the execution engine are appended to the output of the delimited code section.
  • statements within the delimited code section may also invoke one or more local, remote or built-in library functions of the language.
  • the built-in library functions supported for the example Java language include a) an emit() function for converting Java Objects to XML form and appending the resulting value of the function to output of the delimited code section; b) a push(element) function to append a copy of a specified element to the output of the delimited code section and reposition the insertion point for the delimited code section inside the element such that subsequent output of the delimited code section is appended as children of this element; c) a pop() function to "back up" the current insertion point for the delimited code section such that subsequent output of the delimited code section is appended as children of the parent of the element containing the current insertion point; and d) a getDocument()function to retrieve and return a W3C document object for the delimited code section, for use as a space in which new nodes may be created.
  • Figure 2a illustrates the operational flow of the relevant aspects of execution engine 104 in accordance with one embodiment; more specifically, the operational flow of execution engine 104 for processing data processing representation 106.
  • execution engine 104 like other conventional execution engines of prior art data processing representations, upon invocation, would parse and interpret the statements of data processing representation 106.
  • execution engine 104 first locates and processes the declaration statements declaring the programming languages employed in expressing the data processing representation being processed, block 202. Next, execution engine 104 locates the start of the "next" code section, identifies the language associated with code section, and as described earlier, invoke the corresponding language specific processing unit to process the code section, block 204.
  • execution engine 104 determines whether end of execution has been reached, block 208, if not, execution engine 104 continues the process at block 204 again, i.e. determining the language of the "next" code section, and invoke the corresponding language specific processing unit to process the "next" code section. The process continues until eventual execution control is returned where end of execution has been reached.
  • FIG. 2b illustrates the operational flow of the relevant aspects of a language specific processing unit 105 for processing a non-header code section of the language, in accordance with one embodiment.
  • the processing unit first locates the "next" statement to be executed, block 222.
  • the processing unit determines if the it is a statement of the language or of an unknown language (e.g. the start of a language tag of a sub-section of another language), block 224. If it is a statement of an unknown language, as described earlier, the processing unit invokes the execution engine recursively allowing it to evaluate the foreign language section with the other language specific processing units at its disposal.
  • an unknown language e.g. the start of a language tag of a sub-section of another language
  • the language processor determines if it is a statement of the language the language processor the statement elements accordingly, starting with a next statement element, block 226. Again, the processing unit determines if the statement element is an element recognized within the language or it's an element of an unknown language (e.g. the start of a language tag of a sub-section of another language), block 228. If it is an element of an unknown language, as described earlier, the processing unit invokes the execution engine recursively.
  • an unknown language e.g. the start of a language tag of a sub-section of another language
  • the processing unit processes the element accordingly, block 230.
  • the language element may be an invocation invoking a library function of the language. If so, the library function is invoked and executed accordingly.
  • the library function may be local or remote, and invoked in a namespace based approach. Invocation of function in a namespace based approach is the subject matter of Patent Cooperation Treaty (PCT) patent application number ⁇ to be insert>, entitled “Namespace Based Function Invocation", contemporaneously filed, and published on ⁇ insert date>, which claims priority to the earlier enumerated U.S. provisional patent application 60/246,916. Readers are referred to the 'xxx application for further details.
  • PCT Patent Cooperation Treaty
  • the processing unit determines if end of statement has been reached. If not, it continues operation at block 226 again. If end of statement has been reached, the processing unit determines if there are additional statements to be processed, block 234. If so, it continues operation at block 222 again. Otherwise, it returns execution control back to the execution engine.
  • Figure 2c illustrates the operational flow of the relevant aspects of a language specific processing unit 105 for processing a header section of the language, in accordance with one embodiment. More specifically, the embodiment is the embodiment in support of the Java language, incorporating the earlier described features. Other language specific processing units 105 in support of other languages may be likewise implemented with or without modifications and alterations.
  • the exemplary processing unit 105 determines if it is processing a directive or a declarative statement, block 232. If it is a directive statement being processed, the exemplary processing unit 105 performs the specified operation, e.g. an import operation importing enumerated data packages, as directed, block 234. On the other hand, if it is a declarative statement being processed, the exemplary processing unit 105 processes the declaration, e.g. instantiating a declared processing method or an instance variable, as declared, block 236.
  • Example Computer System Figure 3 illustrates a computer system suitable for use to practice the present invention, in accordance with one embodiment.
  • computer system 300 includes one or more processors 302 and system memory 304. Additionally, computer system 300 includes mass storage devices 306 (such as diskette, hard drive, CDROM and so forth), input/output devices 308 (such as keyboard, cursor control and so forth) and communication interfaces 310 (such as network interface cards, modems and so forth).
  • mass storage devices 306 such as diskette, hard drive, CDROM and so forth
  • input/output devices 308 such as keyboard, cursor control and so forth
  • communication interfaces 310 such as network interface cards, modems and so forth.
  • system bus 312 which represents one or more buses. In the case of multiple buses, they are bridged by one or more bus bridges (not shown).
  • system memory 304 and mass storage 306 are employed to store a working copy and a permanent copy of the programming instructions implementing the execution engine and the language specific processing units.
  • the permanent copy of the programming instructions may be loaded into mass storage 306 in the factory, or in the field, through a distribution medium (not shown) or through communication interface 310 (from a distribution server (not shown).
  • the constitution of these elements 302-312 are known, and accordingly will not be further described.

Abstract

A data processing representation (106) is expressed in the form of code sections (110), which may be nested, using multiple programming languages. The representation is read by and execution engine (104). The execution engine indentifies the language of each code section, and a corresponding language specific processing unit (105) is invoked to process the code section. The processing unit reads that section, identifying sub-sections specified in it's associated language and other sub-sections specified in unknown languages. It executes the sub-sections specified in its associated language with the intended in an unknown language is encountered, it delegates processing of that sub-section back to the execution engine, which repeats this process for the unknown sub-section. The execution result is returned back to the requesting language specific processing unit, which continues processing from where it left off.

Description

A Multi-Language Execution Method
Related Applications
This non-provisional application is related to and claims priority to provisional application number 60/246,915, entitled "A Data Processing Method Employing
Cell Based Data Flow Description", and application number 60/246,916, entitled "A Multi-Language Execution Method", both filed on November 10,
2000, and both specifications are hereby fully incorporated by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of data processing. More specifically, the present invention relates to the employment of multiple programming languages interleaved within a single source file for data processing operations.
2. Background Information
Ever since the invention of the first computer, computer scientists have continuously tried to improve the productivity of programmers, such that more applications can be developed using fewer resources to take advantage of the continuous advancements being made in the art of computer and related technologies. First assembler languages were developed to replace machine languages. Then, high level languages, such as FORTRAN, COBOL, PL/I and so forth, were developed to further improve the productivity of programmers. Development of high level languages were followed by structured languages such as Pascal and C, and then object oriented programming languages such as C++. To facilitate development of the Internet and the World Wide Web, "new" languages such as the Hypertext Markup Language (HTML), Java, Javascript, Perl and CGI were developed.
Each programming language has its strength and weakness, and is often suitable for certain applications over other applications. It is often desirable to be able to employ instructions or statements of different programming languages to solve a problem or implement an application. However, few programming languages offer such support. To the extent that mixed language execution is supported, the approach is often proprietary and not extendable to other programming languages. Thus, an improved mixed multi-language method, especially, one that is extensible to multiple programming languages is desired.
SUMMARY OF THE INVENTION
A data processing representation is expressed in the form of code sections, which may be nested, using multiple programming languages. The representation is read by an execution engine. The execution engine identifies the programming language of each code section, and a corresponding language specific processing unit is invoked to process the code section. The language specific processing unit reads that section of the representation, identifying sub-sections specified in it's associated language and other subsections specified in unknown languages. It executes the sub-sections specified in its associated language with the intended semantics and in the appropriate order. When a sub-section specified in an unknown language is encountered, it delegates processing of that sub-section back to the execution engine, which repeats this process for the unknown sub-section. The execution engine coordinates execution of the unknown sub-section, using one or more appropriate language specific processing units, and returns the result back to the requesting language specific processor, which will continue processing where it left off.
In one embodiment, a header section comprising directive and/or declarative statement is also supported for one or more of the languages. Upon recognition, the corresponding language specific processing unit imports data packages enumerated by the directive statement, as directed, or instantiate methods/variables enumerated by the declarative statement, for code sections of the language, as declared. In one embodiment, the mixed usage of at least three programming languages is supported. The first language is an XML-like declarative language, the second language is the Java language and the third language is XML.
BRIEF DESCRIPTION OF DRAWINGS
The present invention will be described by way of exemplary embodiments, but not limitations, illustrated in the accompanying drawings in which like references denote similar elements, and in which:
Figure 1 illustrates an overview of the multi-language execution method of the present invention, in accordance with one embodiment;
Figure 2a illustrates the relevant operational flow of the execution, engine of Fig. 1, in accordance with one embodiment;
Figure 2b illustrates the relevant operational flow of a language specific processing unit of Fig. 1, for processing a code section of the language, in accordance with one embodiment;
Figure 2c illustrates the relevant operational flow of a language specific processing unit of Fig. 1, for processing a header section of the language, in accordance with one embodiment;
Figure 3 illustrates a computer system suitable for use to practice the present invention, in accordance with one embodiment; and
Figure 4 illustrates a multi-language data processing representation of Fig. 1 , in further detail in accordance with one embodiment.
DETAILED DESCRIPTION OF THE INVENTION
The present invention includes a method for specifying data processing operations using programming instructions of multiple programming languages, and for executing the multi-language data processing representation.
In the following description, various aspects of the present invention will be described. However, the present invention may be practiced with only some or all aspects of the present invention. For purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. However, the present invention may be practiced without the specific details. In other instances, well known features are omitted or simplified in order not to obscure the present invention.
Parts of the description will be presented in data processing terms, such as data, variables, methods, import, retrieve, return, and so forth, consistent with the manner commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. As well understood by those skilled in the art, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, and otherwise manipulated through mechanical, electrical and/or optical components of a computer system. The term computer system includes general purpose as well as special purpose data processing machines, systems, and the like, that are standalone, adjunct or embedded.
Various operations will be described as multiple discrete steps in turn, in a manner that is most helpful in understanding the present invention, however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.
The phrase "in one embodiment" is used repeatedly. The phrase generally does not refer to the same embodiment, however, it may.
Overview Referring now to Figure 1 , wherein a block diagram illustrating an overview of the multi-language execution method of the present invention, in accordance with one embodiment. As illustrated, in accordance with the present invention, a computing environment 102 is provided with an execution engine 104, supplemented with a number of language specific processing units 105, to facilitate execution of data processing representations 106 expressed with programming instructions of multiple programming languages. For the embodiment, computing environment 102 is also provided with function libraries 112 of the programming languages.
As illustrated, in accordance with the embodiment, a multi-language data processing representation 106 includes one or more language namespace declarations 108 declaring language or languages employed, and one or more code sections 110 of the declared languages. In other embodiments, other non-namespace means may also be employed to declare the languages involved. As will be described in more detail below, each code section 110 may include sub-sections written in one or more other languages, that is code sections 110 of the different programming languages may be interleaved. Each sub-section may in turn have sub-sub-sections written in other languages, and so forth.
For the embodiment, data processing representation 106 may also include one or more language specific header sections 109 specifying various "preliminary" matters for subsequent code sections 110 of the language.
Execution engine 104 is endowed with logic to anticipate that data processing representations 106 may include code sections of different programming languages, and with the assistance of language specific processing units 105 be able to handle and facilitate execution of these code sections of different programming languages. Moreover, execution engine 104 is endowed with logic to anticipate and handle inter-mixing of code sections of the different programming languages. For the embodiment, upon encountering a code section/statement of a language, execution engine 104 invokes the corresponding language specific processing unit 105 to augment and provide the language specific processing required to process and facilitate execution of the code section/statement.
Language specific processing units 105 are endowed with logic to identify sub-sections written in unknown programming languages, and delegate the processing of those sub-sections back to the execution engine 104. The execution engine 104, in turn, will pass the sub-section to an appropriate language specific processor and return the result to the requesting language specific processing unit 105. In general, except for the teachings of the present invention incorporated in execution engine 104 and language specific processing units
105, and the exploitation of these abilities by data processing representations
106, data processing representations 106 are intended to represent a broad range of data processing representation methodologies known in the art, and execution engine 104 is intended to represent a broad range of the corresponding engines in support of these methodologies. Further, computing environment 102 may be disposed in a single or multi-processor system, or a collection of networked systems. In the case of networked systems, the systems may be networked locally, or across a number of private and/or public networks, including the Internet.
Mixed Language Data Processing Representation Referring now to Figure 4, wherein a block diagram illustrating a mixed language data process representation 106 of Fig. 1 in further details, in accordance with one embodiment is shown. As illustrated, and described
» earlier, for the embodiment, data processing representation 106 includes one or more language namespace declarations 108 declaring one or more languages employed. In one embodiment, declarations 108 are expressed in accordance with the following exemplary syntax:
<xs:xsheet xmlns:xs="xl://crossgain.net/lang/xsheet/" xmlns:java="xl://crossgain.net/lang/java/"> where "xmlns" declares an XML namespace,
"xl://crossgain.net/lang/xsheet/" is a namespace using a specially formed URI identifying one language that may be used in this source. The execution engine uses this URI to locate an appropriate language specific processing unit for sections written in this language. "xl://crossgain.net/lang/java/" is a specially formed URI identifying a second language that may be used in this source (an extension of the well known Java language in this example). The execution engine uses this URI to locate an appropriate language specific processing unit for sections written in this language.
"xs" is a namespace prefix used to identify sections of the source written in the language identified by the associated namespace, "xl://crossgain.net/lang/xsheet/"
"Java" is a namespace prefix used to identify sections of the source written in the language identified by the associated namespace, "xl://crossgain.net/lang/java/"
Cell based data processing is described in U.S. patent application number 09/741 ,219, entitled "Cell Based Data Processing", filed on December 19, 2000, which is a non-provisional application of the earlier enumerated U.S. provisional patent application 60/246,915. Readers are referred to the '219 application for further details.
For ease of understanding, the remaining description of the present invention will be presented primarily in the context of the aforementioned "cell based" methodology/language and the extension of the Java language, the present invention is not so limited. The present invention may be practiced with any two or more currently known or to be developed languages, as long as each of the languages is amenable to the declaration and reference techniques described in further details below.
Continuing to refer to Fig. 4, and as alluded earlier, for the embodiment, data processing representation 106 further includes a number of language specific header sections 109 of selected supported languages. For the embodiment, each header section 109 may include one or more directive statements 402 directing one or more preliminary or preparatory actions, such as importing of data packages, to be performed, and one or more declarative statements 404 declaring one or more processing methods or instance variables to be instantiated for use by subsequent code sections 110 of the language.
In one embodiment, a header section 109 may be declared in accordance with the following exemplary syntax:
<xs:header> <java:directive> import org.w3c.dom.*; </java:directive> </xs:header>
The above example directive directs the import of W3C's definition of the document object model for use by subsequent Java code sections.
Still referring to Fig. 4. as described earlier, data processing section 106 further includes language specific as well as mixed language code sections 110a and 110b. For the embodiment, statements of a second language may be intermixed among statement of a first language, employing one or more sets of delimiting language tag pairs 442a-442b and 444a-444b as shown.
For example, from within Java, retrieval and return of a XML value associated with an xsheet variable as an object may be specified as follows: myvar = <xs:valueof select="$countdown'7>;
The XML value identified by the current value of the xsheet variable "countdown" is retrieved and returned as an object for use in a Java expression. In contrast, consider the following example where the xsheet code is used as a statement instead of part of an expression: for (int j = O; j < 10; j++) {
<xs:value-of select="$countdown"/>;
}
In this case, the Java specific processing unit asks the execution engine to evaluate the xsheet code 10 times. Each time, the results returned by the execution engine are appended to the output of the delimited code section.
As illustrated, for the embodiment, statements within the delimited code section may also invoke one or more local, remote or built-in library functions of the language. In one embodiment, the built-in library functions supported for the example Java language include a) an emit() function for converting Java Objects to XML form and appending the resulting value of the function to output of the delimited code section; b) a push(element) function to append a copy of a specified element to the output of the delimited code section and reposition the insertion point for the delimited code section inside the element such that subsequent output of the delimited code section is appended as children of this element; c) a pop() function to "back up" the current insertion point for the delimited code section such that subsequent output of the delimited code section is appended as children of the parent of the element containing the current insertion point; and d) a getDocument()function to retrieve and return a W3C document object for the delimited code section, for use as a space in which new nodes may be created.
Execution Engine
Figure 2a illustrates the operational flow of the relevant aspects of execution engine 104 in accordance with one embodiment; more specifically, the operational flow of execution engine 104 for processing data processing representation 106. The embodiment, assumes, execution engine 104, like other conventional execution engines of prior art data processing representations, upon invocation, would parse and interpret the statements of data processing representation 106.
As illustrated, for the embodiment, execution engine 104 first locates and processes the declaration statements declaring the programming languages employed in expressing the data processing representation being processed, block 202. Next, execution engine 104 locates the start of the "next" code section, identifies the language associated with code section, and as described earlier, invoke the corresponding language specific processing unit to process the code section, block 204.
Upon return of execution control, execution engine 104 determines whether end of execution has been reached, block 208, if not, execution engine 104 continues the process at block 204 again, i.e. determining the language of the "next" code section, and invoke the corresponding language specific processing unit to process the "next" code section. The process continues until eventual execution control is returned where end of execution has been reached.
Language Specific Processing Unit Figure 2b illustrates the operational flow of the relevant aspects of a language specific processing unit 105 for processing a non-header code section of the language, in accordance with one embodiment. As illustrated, for the embodiment, the processing unit first locates the "next" statement to be executed, block 222. Upon locating the "next" statement, the processing unit determines if the it is a statement of the language or of an unknown language (e.g. the start of a language tag of a sub-section of another language), block 224. If it is a statement of an unknown language, as described earlier, the processing unit invokes the execution engine recursively allowing it to evaluate the foreign language section with the other language specific processing units at its disposal.
If it is a statement of the language the language processor the statement elements accordingly, starting with a next statement element, block 226. Again, the processing unit determines if the statement element is an element recognized within the language or it's an element of an unknown language (e.g. the start of a language tag of a sub-section of another language), block 228. If it is an element of an unknown language, as described earlier, the processing unit invokes the execution engine recursively.
If it is an element recognized by the language, the processing unit processes the element accordingly, block 230. As described earlier, in one embodiment, the language element may be an invocation invoking a library function of the language. If so, the library function is invoked and executed accordingly. The library function may be local or remote, and invoked in a namespace based approach. Invocation of function in a namespace based approach is the subject matter of Patent Cooperation Treaty (PCT) patent application number <to be insert>, entitled "Namespace Based Function Invocation", contemporaneously filed, and published on <insert date>, which claims priority to the earlier enumerated U.S. provisional patent application 60/246,916. Readers are referred to the 'xxx application for further details. Still referring to Fig. 2b, thereafter, at block 232, the processing unit determines if end of statement has been reached. If not, it continues operation at block 226 again. If end of statement has been reached, the processing unit determines if there are additional statements to be processed, block 234. If so, it continues operation at block 222 again. Otherwise, it returns execution control back to the execution engine.
Figure 2c illustrates the operational flow of the relevant aspects of a language specific processing unit 105 for processing a header section of the language, in accordance with one embodiment. More specifically, the embodiment is the embodiment in support of the Java language, incorporating the earlier described features. Other language specific processing units 105 in support of other languages may be likewise implemented with or without modifications and alterations.
As illustrated, upon invocation, the exemplary processing unit 105 determines if it is processing a directive or a declarative statement, block 232. If it is a directive statement being processed, the exemplary processing unit 105 performs the specified operation, e.g. an import operation importing enumerated data packages, as directed, block 234. On the other hand, if it is a declarative statement being processed, the exemplary processing unit 105 processes the declaration, e.g. instantiating a declared processing method or an instance variable, as declared, block 236.
The process continues as earlier described, block 238, until all statements of the header section are processed.
Example Computer System Figure 3 illustrates a computer system suitable for use to practice the present invention, in accordance with one embodiment. As shown, computer system 300 includes one or more processors 302 and system memory 304. Additionally, computer system 300 includes mass storage devices 306 (such as diskette, hard drive, CDROM and so forth), input/output devices 308 (such as keyboard, cursor control and so forth) and communication interfaces 310 (such as network interface cards, modems and so forth). The elements are
π coupled to each other via system bus 312, which represents one or more buses. In the case of multiple buses, they are bridged by one or more bus bridges (not shown). Each of these elements performs its conventional functions known in the art. In particular, system memory 304 and mass storage 306 are employed to store a working copy and a permanent copy of the programming instructions implementing the execution engine and the language specific processing units. The permanent copy of the programming instructions may be loaded into mass storage 306 in the factory, or in the field, through a distribution medium (not shown) or through communication interface 310 (from a distribution server (not shown). The constitution of these elements 302-312 are known, and accordingly will not be further described.
Conclusion and Epilogue Thus, it can be seen from the above descriptions, a novel method and apparatus for processing and facilitating execution of data processing representations encoded using multiple programming languages has been described. While the present invention has been described in terms of the above illustrated embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described. The present invention can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of restrictive on the present invention.

Claims

CLAIMSWhat is claimed is:
1. A method of computing comprising: reading a data processing representation having code sections with code statements of at least a first and a second programming language; recognizing a first code section with at least code statements of a first programming language; invoking a first code statement processing unit of the first programming language to process the first code section; recognizing a second code section with at least code statements of a second programming language; invoking a second code statement processing unit of the second programming language to process the second code section.
2. The method of claim 1 , wherein the first and second code sections are non-overlapping code sections.
3. The method of claim 1 , wherein said second code section is embedded within said first code section.
4. The method of claim 1 , wherein said first language is a directive language, and said second language is a selected one of XML and Java.
5. The method of claim 1 , wherein said first language is Java, and said second language is XML.
6. The method of claim 1 , wherein the method further comprises recognizing a third code section with at least code statements of a third programming language; invoking a third code statement processing unit of the third programming language to process the third code section.
7. The method of claim 6, wherein said third code section is embedded within said second code section, and said second code section is embedded within saicl first code section.
8. The method of claim 6, wherein said first language is a directive language, said second language is Java and said third language is XML.
9. The method of claim 1 , wherein the method further comprises recognizing an invocation of a library function within at least a selected one of said first and second code sections; invoking the library function, and outputting the result of the invocation.
10. The method of claim 9, wherein the library function is a selected one of an emit function for outputting execution results, a pop function for returning an element, and a push function for backing up an insertion point.
11. The method of claim 1 , wherein the method further comprises recognizing a header section of a selected one of the first and the second programming language; recognizing a directive statement within the header section, enumerating one or more data packages; and importing the enumerated one or more data packages for use within code sections with at least statements of the selected first and second programming language.
12. The method of claim 1 , wherein the method further comprises recognizing a header section of a selected one of the first and the second programming language; recognizing a declare statement within the header section, enumerating one or more processing methods; and instantiating the enumerated one or more processing methods for use within code sections with at least statements of the selected first and second programming language.
13. The method of claim 1 , wherein the method further comprises recognizing a header section of a selected one of the first and the second programming language; recognizing a declare statement within the header section, enumerating one or more instance variables; and instantiating the enumerated one or more instance variables for use within code sections with at least statements of the selected first and second programming language.
14. A method of computing comprising: reading a data processing representation having code sections with code statements of at least a first and a second programming language; recognizing a header section of a selected one of the first and the second programming language; recognizing a directive statement within the header section, enumerating one or more data packages; and importing the enumerated one or more data packages for use by code sections within code sections with at least statements of the selected first and second programming language.
15. The method of claim 14, wherein the method further comprises recognizing a declare statement within the header section, enumerating one or more processing methods; and instantiating the enumerated one or more processing methods for use within code sections with at least statements of the selected first and second programming language.
16. The method of claim 14, wherein the method further comprises recognizing a declare statement within the header section, enumerating one or more instance variables; and instantiating the enumerated one or more instance variables for use within code sections with at least statements of the selected first and second programming language.
17. A method of computing comprising: reading a data processing representation having code sections with code statements of at least a first and a second programming language; recognizing a header section of a selected one of the first and the second programming language; recognizing a first declare statement within the header section, enumerating one or more processing methods; and instantiating the enumerated one or more processing methods for use within code sections with at least statements of the selected first and second programming language.
18. The method of claim 17, wherein the method further comprises recognizing a second declare statement within the header section, enumerating one or more instance variables; and instantiating the enumerated one or more instance variables for use within code sections with at least statements of the selected first and second programming language.
19. A method of computing comprising: reading a data processing representation having code sections with code statements of at least a first and a second programming language; recognizing a header section of a selected one of the first and the second programming language; recognizing a declare statement within the header section, enumerating one or more instance variables; and instantiating the enumerated one or more instance variables for use within code sections with at least statements of the selected first and second programming language.
20. An apparatus comprising: at least one storage unit having stored thereon programming instructions designed to enable the apparatus to read a data processing representation having code sections with code statements of at least a first and a second programming language, recognize a first code section with code statements of at least the first programming language, invoking a first code statement processing unit of the first programming language to process the first code section, recognize a second code section with code statements of at least the second programming language, invoking a second code statement processing unit of the second programming language to process the second code section; and at least one processor coupled to said at least one storage unit to execute said programming instructions.
21. The apparatus of claim 20, wherein the first and second code sections are non-overlapping code sections.
22. The apparatus of claim 20, wherein said second code section is embedded within said first code section.
23. The apparatus of claim 20, wherein said first language is a directive language, and said second language is a selected one of XML and Java.
24. The apparatus of claim 20, wherein said first language is Java, and said second language is XML.
25. The apparatus of claim 20, wherein the programming instructions further enable the apparatus to recognize a third code section with at least code statements of a third programming language; invoke a third code statement processing unit of the third programming language to process the third code section.
26. The apparatus of claim 25, wherein said third code section is embedded within said second code section, and said second code section is embedded within said first code section.
27. The apparatus of claim 25, wherein said first language is a directive language, said second language is Java and said third language is XML.
28. The apparatus of claim 20, wherein said programming instructions further enable the apparatus to recognize an invocation of a library function of a selected one of the first and the second programming language within the first code section, invoke the library function, and output the result of the invocation.
29. The apparatus of claim 28, wherein the library function is a selected one of an emit function for outputting execution results, a pop function for returning an element, and a push function for backing up an insertion point.
30. The apparatus of claim 20, wherein the said programming instructions are further designed to enable the apparatus to recognize a header section of a selected one of the first and the second programming language; recognize a directive statement within the header section, enumerating one or more data packages; and import the enumerated one or more data packages for use by code sections with at least code statements of the selected one of the first and the second programming language.
31. The apparatus of claim 20, wherein said programming instructions are further designed to enable the apparatus to recognize a header section of a selected one of the first and the second programming language; recognize a declare statement within the header section, enumerating one or more processing methods; and instantiate the enumerated one or more processing methods for use within code sections with at least code statements of the selected one of the first and the second programming language.
32. The apparatus of claim 20, wherein said programming instructions are further designed to enable the apparatus to recognize a header section of a selected one of the first and the second programming language; recognize a declare statement within the header section, enumerating one or more instance variables; and instantiate the enumerated one or more instance variables for use code sections with at least code statements of the selected one of the first and the second programming language.
33. An apparatus comprising: at least one storage medium having stored therein a plurality of programming instructions designed to enable the apparatus to read a data processing representation having code sections with programming language statements of at least a first and a second programming language, recognize a header section of a selected one of the first and the second programming language; recognizing a directive statement within the header section, enumerating one or more data packages, and import the enumerated one or more data packages for use code sections with at least code statements, of the selected one of the first and the second programming language; and at least one processor coupled to the storage medium to execute the programming instructions.
34. The apparatus of claim 33, wherein said programming instructions are further designed to enable the apparatus to recognize a declare statement within the header section, enumerating one or more processing methods, and instantiate the enumerated one or more processing methods for use within code sections with at least code statements of the selected one of the first and the second programming language.
35. The apparatus of claim 33, wherein said programming instructions are further designed to enable the apparatus to recognize a declare statement within the header section, enumerating one or more instance variables, and instantiate the enumerated one or more instance variables for use within code sections with at least code statements of the selected one of the first and the second programming language.
36. An apparatus comprising: at least one storage medium having stored therein a plurality of programming instructions designed to enable the apparatus to read a data processing representation having code sections with code statements of at least a first and a second programming language, recognize a header section of a selected one of the first and the second programming language, recognize a first declare statement within the header section, enumerating one or more processing methods, and instantiate the enumerated one or more processing methods for use within code sections with at least code statements of the selected one of the first and the second programming language; and at least one processor coupled to the storage medium to execute the programming instructions.
37. The apparatus of claim 36, wherein said programming instructions are further designed to enable the apparatus to recognize a second declare statement within the header section, enumerating one or more instance variables, and instantiate the enumerated one or more instance variables for use within code sections with at least code statements of the selected one of the first and the second programming language.
38. An apparatus comprising: at least one storage medium having stored therein a plurality of programming instructions designed to enable the apparatus to read a data processing representation having code sections with code statements of at least a first and a second programming language, recognize a header section of a selected one of the first and the second programming language, recognize a declare statement within the header section, enumerating one or more instance variables, instantiate the enumerated one or more instance variables for use within code sections with at least code statements of the selected one of the first and the second programming language; and at least one processor coupled to the storage medium to execute the programming instructions.
PCT/US2001/046928 2000-11-10 2001-11-09 A multi-language execution method WO2002039647A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2002220243A AU2002220243A1 (en) 2000-11-10 2001-11-09 A multi-language execution method
US10/089,139 US8156471B2 (en) 2001-11-09 2001-11-09 Multi-language execution method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US24691600P 2000-11-10 2000-11-10
US24691500P 2000-11-10 2000-11-10
US60/246,915 2000-11-10
US60/246,916 2000-11-10

Publications (2)

Publication Number Publication Date
WO2002039647A2 true WO2002039647A2 (en) 2002-05-16
WO2002039647A3 WO2002039647A3 (en) 2002-08-15

Family

ID=26938324

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/046928 WO2002039647A2 (en) 2000-11-10 2001-11-09 A multi-language execution method

Country Status (2)

Country Link
AU (1) AU2002220243A1 (en)
WO (1) WO2002039647A2 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112102844B (en) * 2020-11-09 2021-02-05 苏州思必驰信息科技有限公司 Writing and maintaining method and device for offline recognition of xbnf

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5630137A (en) * 1991-09-06 1997-05-13 International Business Machines Corporation Condition handling in a multi-language computer program
US6066181A (en) * 1997-12-08 2000-05-23 Analysis & Technology, Inc. Java native interface code generator
US6292936B1 (en) * 1998-11-12 2001-09-18 International Business Machines Corporation Enabling multiple runtime processors in an interpreter-based embedded scripting system
US6339839B1 (en) * 1998-11-12 2002-01-15 International Business Machines Corporation Enabling multiple code generators in a translator-based embedded scripting system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5630137A (en) * 1991-09-06 1997-05-13 International Business Machines Corporation Condition handling in a multi-language computer program
US6066181A (en) * 1997-12-08 2000-05-23 Analysis & Technology, Inc. Java native interface code generator
US6292936B1 (en) * 1998-11-12 2001-09-18 International Business Machines Corporation Enabling multiple runtime processors in an interpreter-based embedded scripting system
US6339839B1 (en) * 1998-11-12 2002-01-15 International Business Machines Corporation Enabling multiple code generators in a translator-based embedded scripting system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WALLACE ET AL.: 'Haskell and XML: generic combinators or type-based translation?' ACM September 1999, pages 148 - 159, XP002909586 *

Also Published As

Publication number Publication date
AU2002220243A1 (en) 2002-05-21
WO2002039647A3 (en) 2002-08-15

Similar Documents

Publication Publication Date Title
US8156471B2 (en) Multi-language execution method
US5586328A (en) Module dependency based incremental compiler and method
US5276880A (en) Method for parsing and representing multi-versioned computer programs, for simultaneous and synchronous processing of the plural parses
US6202201B1 (en) Text object compilation method and system
KR20050000352A (en) Common query runtime system and application programming interface
AU2002354768A1 (en) Programming language extensions for processing XML objects and related applications
CA2454608A1 (en) Programming language extensions for processing xml objects and related applications
JPH08339304A (en) Method and apparatus for generation of platform standard object file containing machine independence code
JP2000515281A (en) Method and apparatus for describing interfaces, operations and data types defined by an interface definition language
Bravenboer et al. Generalized type-based disambiguation of meta programs with concrete object syntax
Boshernitsan Harmonia: A flexible framework for constructing interactive language-based programming tools
US7266814B2 (en) Namespace based function invocation
WO2002039647A2 (en) A multi-language execution method
Marlin A distributed implementation of a multiple view integrated software development environment
Lockett et al. Saxon-JS: XSLT 3.0 in the Browser
Cooperman GAP/MPI: Facilitating parallelism.
Munkby et al. Scrap++ scrap your boilerplate in C++
van der Brand et al. Development of parsing tools for CASL using generic language technology
JP2002132502A (en) Automatic creating system and method of distributed object with interpretation of language function
McDonald CMU Common Lisp user's manual Mach IBM RT edition
Brown et al. PTTP+ GLiDeS: Guiding linear deductions with semantics
CN117827171A (en) Method and device for generating project source codes through json schema file
Nilsen A stream data type that supports goal-directed pattern matching on unbounded sequences of values
Benders et al. Compiler Construction A Practical Approach
Watson et al. Practicalities of Syntax Analysis

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 10089139

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP