Computer system to compile non incremental computer source code to execute within incremental type computer system6687896Abstract A computer system 12 which receives non-incremental computer source code which is created and generated from a non-incremental computer system 14 and which places the received non-incremental source code in a parse tree arrangement, thereby enabling the received source code to be developed, compiled, and/or executed with an incremental computer 16 and to be selectively and communicatively exported to a non-incremental computer system. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
aString region Matches.boolean:true
int:0
string: `some string`
int:0
int:5
In the same manner, a method is assigned a selector that embeds the parameter type that it accepts. This allows the Smalltalk.TM. virtual machine to handle most of the method invocations directly. In the cases or situations where the parameter types of the method invocation do not exactly match the parameter types of the available methods, then a second technique is utilized by the computer system 12 of the preferred embodiment of the invention. That is, during compilation or "compile time", the parser 18 will check all method invocations for the existence of any method invocation ambiguities. If the ambiguity remains unresolved, a "compile time error" occurs. Specifically, to handle method lookup at and/or during run-time, a "doesNotUnderstand: method" for Java.RTM. classes as represented in the Smalltalk.TM. system is implemented that has a method lookup algorithm to match a method invocation with the most compatible method signature. If a suitable method is not found or if there are multiple and maximally specific methods, the method invocation is deemed to be ambiguous and a run-time-error occurs. It is known that Smalltalk.TM. numbers do not have size limitations based upon "type" but that Java.RTM. numbers do. Correct Java.RTM. behavior requires, as Applicants have found, that Java.RTM. primitive types are implemented in Smalltalk.TM. in such a way as to emulate the overflow behavior that Java.RTM. primitive types exhibit. Applicants have found that one approach to ensure that this technique is correctly implemented is to implement substantially all of the integer mathematical operations with special methods that take size as an additional parameter. For example and without limitation, according to the teachings of the preferred embodiment of the invention, when the "+" operator is used with integral types, the "+" operator is parsed to send the message #JavaPlus:size: with a byte size parameter that is appropriate for the types of operands (e.g. ints are size 4, longs are size 8). The result of the "message send" operation will be appropriately truncated to the given or specified number of bytes that are specified by the byte size parameter. Applicants have found that floating point types of operations do not require this technique since the Smalltalk.TM. "Float" operations always answer a "Float", and "Double" operations always answer a "Double" and are thus already limited in size in Smalltalk.TM.. The Java.RTM. "Float" and "Double" operations are substantially identical to that found in the Smalltalk.TM. system. Moreover, parser 18, as will be appreciated by one of ordinary skill in the art, will constantly check for parameter type compatibility in substantially all method invocations and arithmetic operators and will enforce accessibility tags or commands, such as and without limitation, "private", "protected", and "public" modifiers in order to substantially ensure the correct compilation of a Java.RTM. method. This "type checking" and "accessibility determination", in one embodiment of the invention, is done by parser 18 during compilation. In the preferred embodiment of the invention, static type methods are implemented as Smalltalk.TM. class methods and static variables are implemented as Smalltalk.TM. class variables. Static variables cannot be implemented as class instance variables since Java.RTM. allows subclasses to have static variables with the same name as static variables in superclasses and are considered different variables with potentially different types. Furthermore, it is undesirable and inappropriate to have class instance variables inherited to subclasses in Smalltalk.TM. when they are not so inherited in Java.RTM.. In Smalltalk.TM. the scope of a class variable would normally extend to subclasses and subclasses are not permitted to define class variables with the same name as class variables defined in superclasses. These constraints can be overridden by the parser in this Java.RTM. system, forceably allowing subclasses to have class variables with the same name as class variables defined in superclasses. The parser handles the correct scoping and accessibility of these class members. Furthermore, in the preferred embodiment of the invention, instance variables, default values, initializers, and static initializers are implemented by special methods which are called when an instance is created or a class is imported as appropriate. In the preferred embodiment of the invention, during instance creation, the instance creation method first instantiates the object using the #new message, in the usual and conventional Smalltalk.TM. manner. Next, a default value is assigned to each instance variable as appropriate for each of the types of variables. Thirdly, any initializer expressions are executed for each instance variable. Lastly, the appropriate constructor method, including any associated arguments, is selected and executed. When a class is imported, either by compiling source files or binary loading as is known and supported within a Smalltalk.TM. implementation, a class is created and compiled in the usual manner within Smalltalk.TM.. Secondly, any and all initializer expressions for all static variables are executed. Lastly, any static initializers for all of the classes are executed. Exception handling, in the preferred embodiment of the invention, is implemented by using the Smalltalk.TM. exception handling mechanism. A class instance variable is defined on the Java.RTM. Throwable class. Each subclass stores a Signal instance and this class instance variable will be used by the parser to generate #handle:do message-sends and #raise message sends to this signal when the parser encounters "try" statements and "throw" statements. Moreover, the Signal instance in each subclass of Throwable is a child signal of the superclass of the Throwable sub-class. The parser generates code to access the Signal as if it were a static method invocation expression. Operators are implemented with conventional and known Smalltalk.TM. methods written to implement the behavior as mandated in the Java.RTM. Language Specification which has been previously incorporated by reference. Smalltalk.TM. compilers disallow assignment to a parameter within a method. The Java.RTM. language allows this type of assignment. Applicants have discovered that this behavior may be achieved by transforming the method parse node so that it will be accepted by the Smalltalk.TM. compiler. The parser tracks the parameters that are being assigned to. After the method node is complete, the parse tree is rebuilt by adding a new temporary variable for each parameter that is being assigned to, inserting a statement at the beginning of the method that does an assignment from the parameter to the new temporary variable. A global replacement of all references to the parameter with the new temporary variable is then done. Synchronized statements and methods are implemented using a Smalltalk.TM. mutual exclusion semaphore. In the preferred embodiment of the invention, the following additions are made to the Java.RTM. grammar to facilitate compilation from within a code browser that displays a single method, constructor, or class definition at a time, or from a text editor for evaluation of arbitrary Java.RTM. expressions:
Method:
ConstructorDeclaration
MethodDeclaration
Dolt:
ImportDeclarationsopt BlockStatementsopt Expressionopt
BlockStatements:
BlockStatement
BlockStatements BlockStatement
ClassDefinition:
ImportDeclarationsopt Modifiersopt class Identifier Superopt
Interfacesopt ClassDefinitionBody
ClassDefinitionBody:
{ ClassDefinitionBodyDeclarationsopt }
ClassDefinitionBodyDeclarations:
ClassDefinitionBodyDeclaration
ClassDefinitionBodyDeclarations ClassDefinitionBodyDeclaration
ClassDefinitionBodyDeclaration:
FieldDeclaration
StaticInitializer
Additionally, there are some enhancements for the Java.RTM. grammar to support communication between Java.RTM. and Smalltalk.TM.. This provides the ability for developers of this system to write code that accesses the Smalltalk.TM. class library for diagnostic and implementation purposes. Note that the word "smalltalk" is a new reserved word for Java.RTM. as enhanced by the computer system of the preferred embodiment of the invention.
StatementExpression:
Smalltalk Expression
Expression:
SmalltalkExpression
SmalltalkExpression:
smalltalk SmalltalkBlock
SmalltalkBlock:
<standard Smalltalk .TM. block syntax for a block with zero
arguments>
ClassOrInterfaceType:
smalltalk SmalltalkClassType
SmalltalkClassType:
name
In the preferred embodiment of the invention, sample parse nodes for an LALR(1) parser are generated for input to a Smalltalk.TM. compiler are provided. The production rules are substantially taken from the Java.RTM. language specification, although exceptions should be noted below. Following the production rule is a schematic for the resulting parse node which, as will be understood by one of ordinary skill in the art, is written in Smalltalk.TM. type pseudo-code. It is assumed, for purposes of the following description, that the parse node for a production rule is left on a stack which is maintained by the parser. The notation used here utilizes names from the production rules to denote parse nodes that are left on the stack as part of the parsing process. Where alternatives are noted, such as Name.vertline.PrimaryNoNewArray, this is an abbreviated way of denoting that either the "Name" parse node is used or the "PrimaryNoNewArray" parse node is used, depending upon which part of the production rule was actually parsed, thereby determining what parse node was left on the stack.
Method:
ConstructionDeclaration
MethodDeclaration
[MethodNode
body: (BlockNode new body:
ConstructorBody.backslash.MethodBody)
arguments: FormalParameterList
selector: (self makeSelectorFrom: Identifier
andArgs: FormalParameterList)]
The parse nodes which are denoted as ConstructorBody, MethodBody, FormalParameterList and Identifier refer to parse nodes which are left on the stack as part of the parsing of ConstructorDeclaration or MethodDeclaration, which includes ConstructorBody, MethodBody, FormalParameterList, and Identifier as part of their own individual production rules as defined in the Java.RTM. Language Specification. Also note that the #makeSelectorFrom:andArgs: method is a supporting method in the parser that constructs a message selector from the method name and the types of the arguments.
DoIt:
BlockStatementsopt Expressionopt
[MethodNode new
selector: #DoIt
block: (BlockNode new
arguments: #( )
body: (SequenceNode new statements:
(BlockStatements
copyWith:Expression)))]
The copyWith: message refers to an operation that appends the argument, here the Expression parse node, to the receiver which is a collection of parse nodes, here BlockStatements.
IfThenStatement:
if (Expression) Statement
[MessageNode new
receiver: Expression
selector: #ifTrue:
argument: (BlockNode new body: Statement)]
IfThenElseStatement:
if (Expression) StatemenNoShortIf else Statement
[MessageNode new
receiver: Expression
selector: #ifTrue:ifFalse:
arguments: (Array with:
(BlockNode new
body: StatementNoShortIf)
with:
(BlockNode new
body: Statement)]
SwitchStatement:
switch (Expression) SwitchBlock
[MessageNode new
receiver: Expression
argument: SwitchBlocks]
In the preferred embodiment of the invention, the #switch: method is a method added to the classes that implement the Java.RTM. primitive types char,byte,short and int which implements the Switch logic. SwitchBlock puts a parse node on the stack that will cause the creation of any Array of Associations at runtime of keys of type char,byte,short or int, and values of the associated switch statement results.
WhileStatement:
while (Expression) Statement
[MessageNode new
receiver: (BlockNode new body: Expression)
selector: #whileTrue:
argument: (BlockNode new body: Statement)
DoStatement:
do Statement while (Expression):
[MessageNode new
receiver: (BlockNode new
body: (Statement copyWith: Expression))
selector: #whileTrue
arguments: #( )]
ForStatement:
for(ForInitopt; Expressionopt; ForUpdateopt) Statement
[SequenceNode new
statements: (ForInit copyWith:
(MessageNode new
receiver: (BlockNode new body: Expression)
selector: #whileTrue:
argument: (BlockNode new
body: (SequenceNode
statements: Statement)))]
ReturnStatement:
return Expressionopt;
[ReturnNode new value: Expression]
FieldAccess:
Primary . Identifier
super . Identifier
[MessageNode new
argument: (builder newLiteralValue: Identifier)
selector: #atField:
receiver: Primary.vertline.super ]
In the preferred embodiment of the invention, the #atField: method is a new method added to Java.RTM. classes that access an instance variable by name. The parser handles accessibility constraints and duplication of field names within the superclass chain.
MethodInvocation:
Name (ArgumentListopt)
Primary . Identifier (ArgumentListopt)
super . Identifier (ArgumentListopt)
[MessageNode new
receiver: self.vertline.Primary.vertline.super
selector: self makeSelectorFrom: Name.backslash.Identifier
andArgs: ArgumentList
arguments: ArgumentList]
In the preferred embodiment of the invention, the #makeSelectorFrom:andArgs: method is a supporting method in the parser that constructs a message selector from the method name and the types of the arguments.
ArrayAccess:
Name [ Expression ]
PrimaryNoNewArray [ Expression ]
[MessageNode new
argument: Expression
selector: #at:
receiver: Name.backslash.PrimaryNoNewArray]
ArrayCreationExpression:
new PrimitiveType DimExprs Dimsopt
new ClassOrInterfacType DimExprs Dimsopt
[MessageNode
receiver: (VariableNode new name: #JavaArray)
selector: #newOfType:dims:isFinal:
arguments: (Array with:
(PrimitiveType.backslash.ClassOrInterfaceType)
with:
(self dynamicArrayCreationNodeWith: DimExprs)
with: (LiteralNode new value: Dims size=0)]
In the preferred embodiment of the invention, first, the parser creates a MessageNode that sends the message #newOfType:dims:isFinal: to the class JavaArray. This method will create an array of the appropriate type and dimensions. The isFinal paramenter is true if there are no empty dims ([ ]) so the basic element types of the array are created and stored in the array. If the isFinal parameter is false, then there were at least one set of empty dims, so the basic element types are not created and stored in the array. Second, the method #dynamicArrayCreationNodeWith: answers a parse node that will cause a Smalltalk.TM. Array to be created at runtime that contains the values of the expression nodes that were passed as parameters to the #dynamicArrayCreationNodeWith: method.
Assignment:
LeftHandSide
AssignmentOperator
AssignmentExpression
[AssignmentNode new
variable: LeftHandSide
value: (MessageNode new
receiver: LeftHandSide
selector: AssignmentOperator
argument: AssignmentExpression)]
In the preferred embodiment of the invention, if the LeftHandSide is a field access or array access expression, then instead of creating an assignment node, the parser, in this context of assignment, changes the field access message from #fieldAt: to #fieldAt:put:, or the array access message from #at: to #at:put:.
ConditionalExpression:
ConditionalOrExpression
ConditionalOrExpression
? Expression : ConditionalExpression
[MessageNode new
receiver: (BlockNode new
body: ConditionalOrExpression)
selector: #ifTrue:ifFalse:
arguments: (Array with: Expression
with: ConditionalExpression)
These techniques can also be used or employed to create interactive development environments with incremental compilation for non-incremental languages other than Java.RTM., such as for and without limitation, the known and commercially available C, C++, and Pascal languages. Data structures that are not "objects" in other languages can be implemented in Smalltalk.TM. as objects. For example, Applicants have found that a C/C++ struct can be created as a Smalltalk.TM. object that stores the data that would otherwise be stored in the structure. Function calls that are not associated with a class can be implemented as class methods within a Smalltalk.TM. class designated to handle global functions. Thus, as described in the foregoing discussion, computer system 12 of the preferred embodiment of the invention receives source code from a non-incremental computer system, recognizes the functionality which must be added in order to allow corresponding actions to be taken in the incremental computer system, parses the received source code, creates a parse tree so that the received source code may be compiled by an incremental computer system, develops/modifies the compiled code, and outputs and/or exports the formatted code to a non-incremental system. Applicants, in this manner, have provided a computer system in which software programs may be developed by use of a non-incremental computer system and yet modified/developed and/or executed or "run" on an incremental system and exported or communicated back to a non-incremental computer system. These non-incrementally developed software programs may also be modified and/or "debugged" on a method basis, as is an inherent incremental system characteristic. Applicants' system therefore combines the advantages and features of both dissimilar systems. It is to be understood that the invention is not limited to the exact construction or method illustrated and described above, but that various changes and modifications may be made without departing from the spirit and the scope of the invention as defined in the following claims.
|
Same subclass Same class Consider this |
||||||||||