text:
A method and apparatus for translating source code written in one computer language to source code written in another language wherein translated static fragments are generated in the face of textual inconsistencies. Exactly one target language definition of each source language static fragment is generated and the differences are encapsulated in new parameters.
1. A method for translating a source program in a first-high level language to a target program in a second high-level language, said method comprising:
producing target program virtual source from a source program in a first high-level language, said virtual source comprising textually different first and second macro expansions corresponding to said first and second invocation expressions, respectively, of a source macro in said source program; and
producing only one target macro in a target program in a second high-level language as the translation of said source macro, said target program comprising first and second invocation expressions of said target macro corresponding to said first and second invocation expressions of said source macro;
checking for said textual differences between said first and second macro expansions; and
encapsulating said textual differences in a new parameter of said target macro.
2. The method of claim 1 wherein said step of checking comprises
calculating respective subsequences of differing tokens, said respective subsequences comprising said textual difference.
3. The method of claim 1 wherein said step of encapsulating comprises
informing a user of said textual difference; and
informing a user of said textual difference; and
requesting a name for said new parameter.
4. The method of claim 1 wherein said step of encapsulating comprises
modifying said source program to include said new parameter in a comment in said source program, leaving unaffected the behavior of said source program.
5. The method of 1, further comprising the step of
producing a fragment tree including textually mismatched first and second macro expansion fragments corresponding to said first and second macro expansions, respectively,
wherein said step of producing said only one target macro comprises
adjusting said first and second macro expansion fragments to include a new parameter encapsulating said textual mismatch.
6. The method of 5 wherein said step of adjusting comprises
performing tree surgery on said fragment tree.
7. The method of 5, further comprising the step of
adjusting a macro expansion fragment of said target macro in said fragment tree to include said new parameter.
8. The method of 5, further comprising the step of
adjusting all macro expansion fragments of said target macro in said fragment tree not including said new parameter to include said new parameter.
9. The method of claim 1, further comprising the steps of
recognizing a second macro in said source program;
recognizing no macro expansion in said virtual source corresponding to said second macro; and
omitting a translation for said second macro in said target program.
10. The method of claim 7 wherein said step of adjusting a macro expansion fragment comprises
traversing a first ordered list of elements in a shallow in-order manner, producing a first ordered yield of elements, and traversing a second ordered list in a shallow in-order manner, producing a second ordered yield of elements;
comparing said first and second yields;
identifying a first element in said first yield and a second element in said second yield, said first and second elements being the respective first element where said first and second yields differ;
identifying a first sub-list of adjacent elements of said first yield beginning with said first element and a second sub-list of adjacent elements of said second yield beginning with said second element, such that removal of the first sub-list from the first yield and removal of the second sub-list from the second yield would cause the first and second removal-modified yields elements to be equivalent;
removing the first sub-list from the first list, thus creating a former position of the first sub-list;
inserting a first new element at the former position of the first sub-list, said first new element representing similarities between said first and second sub-lists and differences between the similarities and the first sub-list.
11. The method of claim 8 wherein said step of adjusting all macro expansion fragments comprises
a. ordering all macro expansion fragments of said target macro, including first- and second-in-order macro expansion fragments;
b. selecting said first- and second-in-order macro expansion fragments as the set and next-in-order macro expansion fragments, respectively;
c. calculating ordered pairs of token subsequences which differ between said set- and said next-in-order macro expansion fragments;
d. continuing from the step of selecting (29.m), if there is no pair of differing token subsequences;
e. otherwise, selecting said first-in-order pair of token subsequences as the next-in-order pair of token subsequences;
f. firstly determining whether a member of said next-in-order pair of token subsequences represents an invocation expression;
g. encapsulating said representing member in a static fragment corresponding to the fragment that said invocation expression invokes, and continuing at the step of selecting (29.l), all if said first determination is TRUE;
h. otherwise, secondly determining whether the first member of said next-in-order pair of token subsequences matches tokens in a first subordinate fragment;
i. encapsulating each member of said next-in-order pair of token subsequences in respective instances of a new static fragment, and continuing at the step of selecting (29.l), all if said second determination is FALSE;
j. otherwise, thirdly determining whether the second member of said next-in-order pair of token subsequences matches tokens in a second subordinate fragment corresponding to said set subordinate fragment;
k. encapsulating the first and second members of said next-in-order pair of token subsequences in respective instances of static fragments corresponding to respective subordinate fragments;
l. selecting the next-in-order pair of token subsequence, if any, and continuing from said step of firstly determining (29.f);
m. otherwise, selecting either of said set and next-in-order macro expansion fragments whose token subsequence was encapsulated in said encapsulation of steps (29.g), (29.i) or (29.k) as the set macro expansion fragment, selecting the next-in-order macro expansion fragment, if any, and continuing from said step of calculating (29.c);
n. otherwise, ending said method, if a next-in-order macro expansion fragment is not selectable.
12. The method of claim 5 wherein said step of adjusting a macro expansion fragment to encapsulate comprises
allocating an encapsulation expansion fragment to encapsulate said textual mismatch;
creating an invocation expression for said encapsulation expansion fragment;
associating said invocation expression with said encapsulation fragment;
removing the text of said textual mismatch from said macro expansion fragment;
adding said encapsulation fragment to said macro expansion fragment where said text was removed from said macro expansion fragment; and
adding said removed text to said encapsulation expansion fragment.
13. The method of claim 5 wherein said step of adjusting a macro expansion fragment to encapsulate comprises
linking an invocation expression for an encapsulation fragment that is an instance of a static fragment to said encapsulation fragment;
removing tokens from a location in a first fragment in which said token subsequence resides;
adding said invocation expression to said first fragment at said location no longer occupied by said tokens; and
placing token in said encapsulation fragment.
14. A system for translating a source program in a first high-level language to a target program in a second high-level language, said system comprising:
a central processing unit;
a memory unit, coupled to said central processing unit, said memory unit including a computer usable medium for data storage wherein is located a computer readable program code for translating a source program in a first high-level language to a target program in a second high-level language, said computer readable program code including;
computer readable program code for producing a target program virtual source from a source program in a first high-level language, said virtual source comprising textually different first and second macro expansions corresponding to first and second invocation expressions, respectively, of a source macro in said source program; and
computer readable program code for producing only one target macro in a target program in a second high-level language as the translation of said source macro, said target program comprising first and second invocation expressions of said target macro corresponding to said first and second invocation expressions of said source macro.
This application is a division of application Ser. No. 08/332,966, filed Nov. 1, 1994, U.S. Pat. No. 5,842,204 which in turn is a continuation-in-part of application Ser. No. 08/319,682, filed Oct. 7, 1994 U.S. Pat. No. 5,768,564.
This invention relates to automated translation between high-level computer programming languages.
This invention relates particularly to improved preservation in a target high-level computer language of invocation expressions and preprocessor characteristics (such as macros, source file inclusion structure, and commentary) contained in a source high-level computer language.
High-level computer languages enable computer programmers to communicate with computers. Statements programmers write in a computer language form a computer program which in turn instructs a computer to perform a set of tasks. "Compilation" is the process of converting high-level computer language programs into instructions, generally called machine code, which the computer can understand and execute. A compiler is a computer program which performs this translation.
In general, each brand of computer understands a different set of machine code instructions. Therefore, a different compiler must exist for each computer to translate a high-level computer language. Because compilers for every high-level computer language do not exist for every brand of computer, not every program can execute on every machine. Programmers can only write programs in the languages for which compilers exist for their target computers.
Nonetheless, it is highly desirable to have a single computer program run on as many brands of computers as possible. Application programs are typically complex and difficult to write; rewriting programs in multiple languages to run on multiple brands of computers is impractical. Likewise, compilers are difficult to write; providing them for every language for every brand of computer is equally impractical. One way of addressing these problems has been the development of well known, widely used, standardized high-level languages. Compilers for these languages are available for a wide variety of computers.
The development of standardized languages has not been a complete solution. There exist numerous high-level languages, and many large programs written in them, which are exotic, highly specialized, little used, obsolete, or designed for specific computers. Many computers do not have compilers available for these languages.
Because many high-level computer languages, whether or not they are standardized, cannot be compiled on every computer, programs must be translated to other languages. While translation can be done by hand, it is a laborious, time consuming, and expensive process prone to error. To address this problem, automatic translators have been and continue to be developed to translate programs written in one high-level language to another.
Automatic translators may be used in either of two distinct strategies to solve the problem of an unavailable compiler for a particular language on a particular computer. First, programmers may continue to write and maintain programs in the original source language. The translator converts these programs into intermediate code in a target language. An available compiler for the target language then converts this intermediate code into machine code which the target computer can understand. Although the target language is usually a standard, widely available language, the translator does not have to produce readable or maintainable source code.
The second strategy requires a translator to produce readable and maintainable code. Programmers going this route want to abandon the original language in favor of the target. Building this type of translator is a more difficult task and is the focus of this invention.
Prior art attempts to build translators which produce readable code have had differing goals and various levels of success. Syntax of some high-level languages has been successfully transformed into syntax of other high-level languages. Some translators have produced attractively formatted target code. While source code comments have been migrated to target code, their placement has not always been optimal. Translators have also attempted to transform the style of programs to make them more readable. Others have used knowledge-based systems to extract the meaning of the source program and rewrite it in the target language.
However, prior art translators fail to preserve programming constructs known as preprocessor characteristics. Many high-level languages include a preprocessor language separate from but coexisting with the language itself. Characteristics of the preprocessor language may include a conditional compilation mechanism, a macro mechanism, a source inclusion mechanism, a variety of compiler directives, and a comment mechanism. Some of the preprocessor features allow programmers to use shorthand invocation expressions for longer constructs. Thus, invoking the shorthand expression triggers a text substitution when the source code is run through the preprocessor.
The ancestor application Ser. No. 08/319,682 describes a method for translation of text substitution preprocessor characteristics. One important aspect of the method described therein is that the text invoked by invocation expressions (for example, text included from another file, text that is the body of an expanded macro, macro actual parameter text that has been substituted in place of a macro formal parameter) must be translated in its context of use. These substitution text sources are called "static fragments". The static fragments cannot be translated immediately at their points of definition because even if the text could be parsed, semantic analysis is not possible. Static fragments are, therefore, translated after their invocations have been expanded and analyzed in their contexts of use.
It is possible that the source language text associated with an invocation expression might translate to different target language text in different contexts of use. A textual mismatch might occur, for example, when type compatibility rules are more strict in the target language than in the source language, requiring a type cast where none appeared in the source language. If the type cast were different in different contexts of use, a textual mismatch would occur.
A source-to-source translator must select a strategy for generating translated static fragments in the face of textual inconsistencies. One possible method is to generate more than one target language definition of the static fragment. This strategy presents readability and maintainability problems; a single point of definition is desirable.
The present invention is directed to a method and apparatus for a source-to-source translator. A specific object of the present invention is to provide a strategy for generating translated static fragments in the face of textual inconsistencies. The method described generates exactly one target language definition of each source language static fragment and encapsulates the differences in new parameters.
It is a further object of the present invention to provide a method and apparatus for "tree surgery;" the dissection of a hierarchical tree data structure and the insertion of a node at the point of the dissection.
Other and further objects of the present invention will be apparent from the following description and claims and are illustrated in the accompanying drawings which, by way of illustration, show preferred embodiments of the present invention and the principles thereof and what are now considered to be the best mode contemplated for applying these principles. Other embodiments of the invention embodying the same or equivalent principles may be used and structural changes may be made as desired by those skilled in the art without departing from the present invention and the purview of the appended claims.
In the drawings:
FIG. 1 depicts a prior art tree data structure.
FIG. 2A depicts a hierarchical tree structure before encapsulating tree surgery.
FIG. 2B depicts a hierarchical tree structure before encapsulating tree surgery.
FIG. 2C depicts the hierarchical tree structure of FIG. 2A after encapsulating tree surgery.
FIG. 2D depicts the hierarchical tree structure of FIG. 2B after encapsulating tree surgery.
FIG. 3 is a simplified block diagram of a computing system for use with the present invention.
FIG. 4 illustrates the source code to source code translator of the present invention in simplified form.
FIG. 5 is a flowchart of the method of the current invention for consistency checking between a current translation session and a prior session.
FIG. 6 is a flowchart of the method of the current invention for consistency checking among fragments produced by a current translation session.
FIG. 7 is a flowchart of the method of the current invention for encapsulating a token subsequence.
FIG. 8 is a simplified block diagram illustrating two translation sessions using the same included file.
FIG. 9 is an example of a virtual fragment tree.
FIG. 10 is a second example of a virtual fragment tree.
FIG. 11 is an example of the use of a ghost formal.
FIG. 12 is an second example of the use of a ghost formal.
FIG. 13 is an example of a virtual fragment tree that contains a use of a macro parameter.
FIG. 14 is a second example of a virtual fragment tree that contains a use of a macro parameter.
FIG. 15 is an example of the reuse of a formal parameter.
FIG. 16 is a second example of the reuse of a formal parameter.
FIG. 17 is an example of a virtual fragment tree into which a formal use has been introduced.
FIG. 18 is an example of a virtual fragment tree.
FIG. 19 is an example of the virtual fragment tree of FIG. 18 into which a formal use has been propagated.
This section describes translation of macro definitions during source-to-source translation even when translation inconsistencies appear between two uses of one macro in different contexts. The Rosetta Translator implements this technique.
The following concepts are key to this description of a method for preserving macros:
Virtual Source A program's virtual source is the stream of tokens that a compiler parses to create a syntax tree representing a program. Virtual source does not necessarily exist in textual form in any single source file; the token stream is created by a series of macro expansions, macro formal parameter substitutions, and source inclusions.
Fragment A fragment represents the result of a macro expansion, a macro actual parameter substitution, or a source file inclusion. These preprocessor mechanisms can appear anywhere in a source file and yield any portion of a syntactic construct; they need not honor syntactic construct boundaries.
Fragment Tree A fragment tree represents expansions of macros, substitutions of macro actual parameters, and inclusions of source that were used by the scanner or preprocessor to create the program's virtual source.
Fragment Consistency
The Rosetta Translator pieces together textual representations of target language fragments to form target language output files, fitting a textual representation of a macro body, for example, into its definition. Because the Rosetta Translator's design requires that each source language macro maps to exactly one target language macro, it checks that every macro use is textually identical, to ensure that the macro text "works" in all contexts of use. The scope of a macro actual parameter is limited to the macro body itself, so the Rosetta Translator need only check that all expansions of a formal parameter within a given macro expansion are textually identical.
Fragments Containing Puns or New Semantic Information
When the syntax for expressing two different operations is different in the target language but the same in the source language, a fragment translation might not "work" in every context of use. In programming languages as in natural language, puns tend to translate poorly. When type compatibility rules differ between the two languages, type casts can lead to a mismatch in macros that are used in conjunction with multiple types. When the translated code requires different semantic information from the original code, different contexts of use can also yield a mismatch.
The following example illustrates an error condition: the translation of two expansions of the same macro result in different macro body text. All instances of a macro body must be checked for consistency before output source generation. The Rosetta Translator generates references to macros, such as "-- redef" and "-- tobitfield" in this example, that encapsulate the emulation of difficult pTAL features. In this case, the integer field "a" overlays the bit field "k". The "-- tobitfield" macro takes the name of the surrounding class type as a parameter.
That name is different for the two uses of the macro: "f-- " versus "g-- ". The following example depicts a macro whose two uses result in macro body text that does not match; mismatching tokens are in bold.
______________________________________pTAL Macrodefine fields = int a [0:-1]; unsigned(1) k #;pTAL Code C++ Codestruct f; class f-- {begin fields; fields; } f;end;struct g; class g-- {begin fields; fields; } g;end;pTAL Expansion C++ Expansionstruct f; class f-- {begin -- redef(short, a, int a [0:-1]; -- tobitfield(f--, k)); unsigned(1) k; unsigned k:1;end; } f;struct g; class g-- {begin -- redef(short, a, int a [0:-1]; -- tobitfield(g--, k)); unsigned(1) k; unsigned k:1;end; } g;______________________________________
Blurred Fragment Boundaries
If a construct translation blurs fragment boundaries, the translated fragment tree looks as if two instances of the fragment were created, and the contents of those fragments are not textually identical. Fragment boundary violations are detected by the same fragment consistency check that detects puns that do not work. The following example illustrates a blurred fragment boundary in a use of an ill-formed macro.
If precedence rules differ between the two languages, then introducing parentheses to preserve the original expression's semantics can lead to a consistency violation. The pTAL language assigns higher precedence to the left shift operator than to the addition operator. The C++ language assigns higher precedence to the addition operator than to the left shift operator. Parentheses appear in the target language version of the expression to retain the order of evaluation. The parentheses tokens happen to be generated from the higher precedence operator, which determines their fragment assignment.
______________________________________ pTAL Code define fred(p) = p << 2#; . . . a := fred (x + 1) ; Expansion of pTAL Code a := x + 1 << 2 ; Generated C++ Code a = x + ( 1 << 2 ) ;______________________________________
The translation of the previous example results in a C++ fragment tree that appears to have two instances of the actual parameter fragment which do not contain identical text.
Minimizing Inconsistently Translated Macros and Macro Actual Parameters
Inconsistently translated macro bodies and macro actual parameters can be minimized by building special rules into the token mapping algorithms, when possible.
Suppress simplifying transformations on the Generated code when inside of a macro expansion. Generally, syntax transformations are not sensitive to whether or not the generated code is inside of a macro body expansion or macro formal parameter expansion. Some routines that perform construct translations are sensitive to fragment boundaries, though they do not translate fragments. These routines suppress simplifying transformations within a macro expansion or macro formal parameter expansion in order to make translations for different macro invocations textually identical. For example, the transformation simplifying the text "&arrayvar[0]" to "arrayvar" is suppressed within a macro when the index is in a macro parameter. Likewise, the transformation simplifying the text "(*ptr).field" to "p→field" is suppressed when "*p" is a macro actual parameter.
Absorb tokens that differ between invocations of a macro into an actual parameter, when possible. Source language tokens might generate not only the logical translation of themselves, but also some attendant baggage. If that baggage can differ in two different invocations of the same macro, there is no problem if the baggage is mapped to the actual parameter rather than the macro body. For example, C++ parentheses generated to force the appropriate operator precedence should be absorbed into the translated actual parameter if they surround C++ tokens generated only from pTAL actual parameter tokens.
Likewise, if a C++ "*" operator was generated in the translation of an implicitly dereferenced pointer in a macro actual parameter, the "*" operator should be absorbed into the translated actual parameter so that nonpointer variables can be passed into the macro.
Extrude tokens that differ between invocations of a macro into the fragment containing the macro invocation syntax. Similar to the previous description, if the differing tokens are on the edge of the C++ translation of a macro body, there is no problem if they are mapped outside. For example, if a C++ type cast applies to an entire macro expansion, then the generated text should show the type cast applied to the macro invocation syntax.
Remedies For Inconsistently Translated Macros and Macro Actual Parameters
Although a careful design of token associations, taking into account common coding practices in the source language, can ensure that fragment mismatch problems are a rare event, it cannot prevent all possible problems. When an inconsistently translated macro or macro actual parameter occurs, the user can choose from three remedies. Each of the remedies can solve any fragment mismatch problem. If the macro in question is exported, changing the macro interface in the original language implementation is usually not possible.
Recode the macro body so that the translation "works." This is viable if recoding the body of the macro avoids the problematic construct and does not disturb the interface or the usage of the macro. If recoding the macro requires changes at all points of use, then this might not be a viable solution.
Give the Rosetta Translator permission to expand all uses of the macro. This eliminates any fragment mismatch problem at the cost of deimplementing the macro that contained a problem. It is not a desirable solution if the macro was useful for improving the usability, maintainability, or readability of the software, or if the macro was exported. It is a viable solution if the product maintainer is not interested in preserving the macro. The following is an example.
______________________________________ pTAL Code define !expand! shifty (x, y) = x << y#; a := shifty(2, 3); Generated C++ Code a = 2 << 3;______________________________________
Give the Rosetta Translator permission to create an additional macro parameter to encapsulate the differences. This eliminates any fragment mismatch problem. It has the potential of producing actual parameters in the target language code that are less sensible than a programmer would write.
Recalling the example of a mismatching macro body from Example 1, the differences can be encapsulated as shown in the following example.
______________________________________pTAL Macro!zero-length array causes a to overlay k!define fields !FORMAL:stype! = int a [0:-1]; unsigned(1) k #;Generated C++ Macro#define fields(stype) \ -- redef(short, a, -- tobitfield(stype, k)); \ unsigned k: 1pTAL Code Generated C++ Codestruct f;begin class f-- { fields; fields(f--);end; } f;struct g; class g-- {begin fields (g--); fields; } g;end;______________________________________
Encapsulating Macro Body Mismatches and Actual Parameter Mismatches
This section describes the target language fragment tree transformations necessary to encapsulate textual mismatches between two expansions of a macro.
Textual Mismatches
Because the Rosetta Translator is designed to generate exactly one target language macro corresponding to each source language macro, it performs a consistency check on every target language instance of each macro body and each macro actual parameter, to ensure that they translate to the same target language text in every context of use. If they do not match, it is an error condition. Example 1 illustrates this error condition.
On encountering a mismatch between two expansions of one macro, the Rosetta Translator calculates the subsequences of differing tokens. The differences appear as follows. The bracketed tokens are boundaries of the mismatch, and are not included in the new actual parameter. If one token subsequence is empty, the boundary tokens show where to place the formal parameter. ##EQU1##
When the fragment mismatch occurs in a target language macro body or macro actual parameter, the Rosetta Translator emits a diagnostic suggesting that the user remedy the problem by specifying a new formal parameter to encapsulate the difference.
Specifying Ghost Parameters
The encapsulation of textual differences in a parameter in a translated macro's definition and invocations is a useful remedy for errors arising from textually inconsistent translations of different expansions. We call this new parameter a "ghost" parameter.
The user specifies a meaningful formal parameter name in a special comment in the macro definition. The comment does not disturb the behavior of the original source code. The following example illustrates the specification of a ghost parameter.
______________________________________ pTAL Code !zero-length array causes a to overlay k! define fields !FORMAL:stype!= int a [0:-1]; unsigned(1) k #;______________________________________
A ghost parameter exists in the translated target language versions of a macro; only the comment specifying the ghost formal parameter name appears in the source language code.
Introducing Ghost Formal Uses to Encapsulate Mismatches
Recall from Example 1 the textual differences in the macro expansion.
______________________________________pTAL Expansion C++ Expansionstruct f; class f-- {begin -- redef(short, a, int a [0:-1]; -- tobitfield(f--, k)); unsigned(1) k; unsigned k:1;end; } f;struct g; class g-- {begin -- redef(short, a, int a [0:-1]; -- tobitfield(g--, k)); unsigned(1) k; unsigned k:1;end; } g;______________________________________
The C++ fragment subtrees in FIG. 9 and FIG. 10 illustrate that the two instances of the macro expansion contain subsequences of tokens that do not match textually.
The Rosetta Translator adjusts the target language fragment tree to introduce a use of the ghost formal parameter, as illustrated by FIG. 11 and FIG. 12. The dashed line indicates an instance of the actual parameter.
The Rosetta Translator generates the following text after ghost parameter substitution:
______________________________________pTAL Macro!zero-length array causes a to overlay k!define fields !FORMAL:stype! = int a [0:-1]; unsigned(1) k #;C++ Macro/*zero-length array causes a to overlay k*/#define fields(stype) \ -- redef(int, a, -- tobitfield(stype, k)); \ unsigned k:1pTAL Code C++ Codestruct f; class f-- {begin fields(f--); fields; } f;end;struct g; class g-- {begin fields(g--); fields; } g;end;______________________________________
Propagating Ghost Formal Uses to Subsequent Macro Expansions
When a ghost formal use is introduced into a macro expansion, then all other expansions of that macro must take on an analogous ghost formal use. A comparison between the other fragments representing expansions of that macro and a fragment into which the formal use was introduced reveals a textual mismatch between the formal use and tokens that await encapsulation in the other fragments. For example, if the macro "fields" were used in a third place, then a comparison of the tokens in each macro expansion would reveal a mismatch between a token representing the formal parameter name and tokens that should be encapsulated within a new use of the formal.
______________________________________C++ Macro/*zero-length array causes a to overlay k*/#define fields(stype) \ -- redef(int, a, -- tobitfield(stype, k)); \ unsigned k:1pTAL Codestruct h;begin fields;end;pTAL Expansion C++ Expansionstruct h; class h-- {begin -- redef(short, a, int a [0:-1]; -- tobitfield(h--, k)); unsigned(1) k; unsigned k:1;end; } f;______________________________________
The differences appear as follows; the bracketed tokens are synchronization points: ##EQU2##
The Rosetta Translator notices that the only token in the first differing subsequence is the name of a macro formal parameter, and introduces a new formal use in the second fragment encapsulating the tokens in that parameter.
______________________________________pTAL Code C++ Codestruct h; class h-- {begin fields(h--); fields; } f;end;______________________________________
Earlier in this paper, we mentioned that the bodies of unused macros are not translated, and shared interface files containing macro definitions tend to be translated incrementally, as a side effect of translating the modules that use them. The Rosetta Translator performs a consistency check between each macro body and that produced, if any, during a previous translation session. It must propagate any ghost formal parameter uses from previous translation sessions into the current translations of the macro body, as shown in the last example.
FIG. 17 illustrates a macro expansion into which a formal has been added to encapsulate a difference with a second macro expansion. FIG. 18 illustrates a third macro expansion. The formal use from the first macro expansion is propagated into the third, yielding the macro expansion depicted in FIG. 19.
Multiple Uses of a Formal Parameter
When multiple mismatches are textually identical, then they can be encapsulated in the same formal parameter. For example, if the define "fields" were expanded to contain two integer fields that overlay bit fields, then there would be two textually identical mismatches. Both sets of differences can be resolved with one ghost parameter.
______________________________________pTAL Macro!zero-length array causes a to overlay k!define fields !FORMAL:stype! = int a [0:-1]; unsigned(1) k; int b [0:-1]; unsigned(1) x#;C++ Macro/*zero-length array causes a to overlay k*/#define fields(stype) \ -- redef(short, a, -- tobitfield(stype, k)); \ unsigned k:1; -- redef(short, b, -- tobitfield(stype, x)); \ unsigned x:1pTAL Code C++ Codestruct f; class f-- {begin fields(f--); fields; } f;end;struct g; class g-- {begin fields(g--); fields; } g;end;______________________________________
FIG. 13 and FIG. 14 illustrate a textual mismatch in two instances of a fragment with an existing formal use. FIG. 15 and FIG. 16 depict the reuse of the formal parameter to encapsulate the textual mismatch. The following example code is illustrated in these figures.
______________________________________pTAL Macrodefine struct-- decl (sname) = struct sname; begin int a[0:-1]; unsigned(1) k; end#;pTAL Codestruct-- decl(f);struct-- decl(g);pTAL Expansion C++ Expansionstruct f; class f-- {begin -- redef(short, a, -- tobitfield(f--,k)); int a[0:-1]; unsigned k:1; unsigned(1) k; }end;struct g; class g-- {begin -- redef(short, a, -- tobitfield(g--,k)); int a[0:-1]; unsigned k:1; unsigned(1) k; };end;C++ Codestruct-- decl(f--);struct-- decl(g--);C++ Macro#define struct-- decl(sname) \ class sname { \ -- redef(short, a, -- tobitfield(sname,k)); \ unsigned k:1; \ }______________________________________
Actual Parameter Mismatches
When the Rosetta Translator detects a mismatch between two expansions of a macro formal parameter in the same macro expansion, there is a potential error condition. Again, if a new formal is available, a use of the new formal is substituted in place of one of the parameters.
Augmentation--As in the context "invocation expression augmentation"--augmentation means adding additional expressive elements, for example adding additional actual macro parameters to an invocation expression which is a macro invocation.
Automatic Translator--A computer program which translates computer programs written in one programming language (the "source language") into semantically equivalent programs in another programming language (the "target language".)
C++--The industry-standard programming language which the Rosetta translator uses as its target language.
Cast--Same as "Type Cast".
Code File--A file containing machine instructions; usually a code file may be loaded into random access memory and executed directly by a computer.
Comment--Explanatory text placed within a computer program which is ignored by the compiler, and therefore has no effect on what the program actually does when it runs. Comments must be specifically delimited so that the compiler knows to ignore them. For example, in C++, text between the character pairs "/*" and "*/" is treated as commentary.
Comment Mechanism--The means by which comments are delimited in a program source and ignored by the compiler; see "Comment".
Compilation--The process by which a compiler translates a program source into an executable code file.
Compiler--A program which performs the process of compilation. Most often, a compiler is used to translate from program source written directly by a programmer into a code file suitable for direct execution by a computer.
Compiler Directive--A programming language construct typically considered "outside" the actual programming language which controls some aspects of a compiler's behavior, such as whether a listing of the program being compiled is produced or not.
Computer Programming Language--The set of rules by which a computer program may be specified. These rules specify such things as how memory locations are named, and how operations are performed on data in those locations.
Computer Language--Same as "Computer Programming Language".
Computer Program--Generic term for a set of instructions to control the operation of a computer. The term "computer program" is used to refer either to a program source as written by a programmer, or the code file produced by compiling a program.
Conditional Compilation Mechanism--Means of specifying whether or not certain sections of program text should be ignored by a compiler, depending on the setting of named or numbered switches. Such regions are specifically delimited by special markers which name the switch. Conditional compilation is useful, for example, in getting a program to behave slightly differently when it is compiled with the different switch settings.
Context of Use--The set of identifiers which are "in scope" at the point in a program's source where a construct is used, and the relative position of the construct within containing constructs, is called its "context of use".
Define--Synonym for "macro".
Encapsulation--Figuratively, to hide something within a wrapper or capsule. In the context of "encapsulating fragment differences", this is done by representing a subsequence of tokens in one virtual fragment which differs from a subsequence of tokens in another virtual fragment corresponding to the same static fragment in interposed virtual fragments whose invocation syntaxes will be the same for both of the original virtual fragments. This effectively hides, or encapsulates, the text differences from the two virtual fragments. For example, if two virtual fragments are instances of the same static fragment which is a macro, but there is a textual difference between the text rendering of the two virtual fragments, then that difference can be encapsulated in a macro actual parameter substitution. Each virtual fragment gets a new virtual fragment whose invocation syntax is the name of a new formal parameter; this takes the place of the differing token subsequences, which become macro actual parameters augmenting the invocation expression of the macro at its sites of call.
Encapsulating Fragment--A fragment used to encapsulate differences between two virtual fragments which are instances of the same static fragment. See discussion under "Encapsulation", above.
File--A computer memory, usually kept on durable media such as magnetic disk. Files can typically be located by name and can be created, written, read, and deleted.
Fragment--A fragment represents the ordered sequence of tokens resulting from a macro expansion, a macro actual parameter substitution, or a source file inclusion. These preprocessor mechanisms can appear anywhere in a source file and can yield any portion of a syntactic construct; they need not honor syntactic construct boundaries. A fragment may contain tokens representing invocation expressions for nested fragments.
Fragment Boundary--The first and last tokens of the contiguous ordered token sequence which forms a fragment.
Fragment Tree--A fragment tree represents the macro expansions, macro actual parameters substitutions, and source file inclusions which were used by the scanner or preprocessor to transform the program source files into the program's virtual source.
Fragment Mismatch--If the translation of two instances of the same static fragment do not have identical text, then the textual differences are referred to as fragment mismatches.
Ghost Formal Parameter--A macro formal parameter which exists in the target language text but not in the source language text.
High-Level Computer Programming Language--A computer programming language which is relatively independent of the instruction set to which it is compiled. High-level computer languages are considered "good" because they can be compiled and run on more than one brand or model of computer.
Instance--The instantiation of a programming language construct. For example, if a macro "m" is used 10 times at different places in a program source, then the point of each use, plus the text generated by that use, form a single instance of the macro, for a total of 10 instances.
Invocation Expression--A sequence of tokens which indicates that the compiler or text preprocessor should perform a particular text substitution. For example, an invocation expression in the programming language C++ which indicates that the contents of the source file `f.h` should be substituted at the point of the invocation expression is `#include "f.h"`.
Machine Code Instruction--(also "machine instruction")--The specification of an operation which can be performed directly by a computer. For example, adding the contents of two memory registers.
Machine Instruction--Synonym for "Machine Code Instruction".
Macro--(also "Define")--A named sequence of tokens which a compiler or preprocessor will substitute for a use of the name within program source. Macros may also have formal parameters, which are just names specified with the definition of the macro. For each formal named, a separate sequence of tokens must be provided at the site of the macro invocation; the compiler or preprocessor will then substitute these latter sequences at each point of the macro expansion where the name of the formal is used in the macro definition.
Macro Actual Parameter--A sequence of tokens provided at the site of a macro invocation, corresponding to a macro formal parameter specified in the definition of the macro. Correspondence is established positionally; the first sequence of tokens is substituted at every point the first macro formal parameter is named in the macro body, and so on.
Macro Actual Parameter Substitution--The fragment of program source produced by substituting a macro actual parameter for a macro formal parameter within the expansion of a macro.
Macro Expansion--The fragment of program source produced by substituting the sequence of tokens defined to be the body of a macro, at a point where the macro is named in a program source.
Macro Formal Parameter--An identifier declared in a macro definition, and used (named) zero or more times in the body of the macro. At each point where the formal parameter is named in the macro body, the sequence of tokens provided at the point of macro invocation as the corresponding macro actual parameter will be substituted within the macro expansion.
Macro Interface--The syntax by which a macro is invoked. This always includes the name of the macro. It will include a parenthesized list of macro actual parameters if any macro formal parameters are specified in the macro's definition; there must be one actual parameter for each formal parameter.
Macro Invocation--The use of a macro name within program text, resulting in the preprocessor or compiler substituting the body of the macro at that point in the program source.
Macro Mechanism--The means by which macros are specified, invoked, and expanded in the processing of a program source.
Order-Adjacent Children--In the context of doing a shallow in-order traversal of the children of a node in a hierarchical tree, order-adjacent children are any subset of the children where the members of the subset are all visited by the in-order traversal without visiting any children of the node which are not in the subset.
Parsing--A means of determining the syntactic structure of a source program. Figuratively, if the tokens of a source program are like the words of a book, parsing acts as the means of recognizing the sentence, paragraph, section, and chapter structure of the book. In practice, parsing of program source may be done by many alternative methods, such as recursive descent, LL(1) parsing, and LR(1) parsing. See Aho, Sethi, and Ullman, Compilers: Principles, Techniques, and Tools, Addison-Wesley, 1985.
Point of Definition--The point in a program source where a construct is initially named and otherwise specified.
Preprocessor Characteristics--Synonym for "virtual source production mechanisms".
Preprocessor Language--The rules by which preprocessor characteristics are interpreted by a compiler or preprocessor.
Preprocessor Mechanism--Synonym for "virtual source production mechanism".
Program--Same as "Computer Program".
Program Source--The memory (one or more source files) in which the text representing a computer program resides.
Programming Language--Same as "Computer Programming Language".
Programmer--An individual who writes a computer program.
Proprietary High-Level Language--A programming language whose definition is owned by a given company, rather than being in the public domain. Proprietary languages are typically developed for special purposes, or are historical artifacts.
Ptal--"Portable Transaction Application Language". The proprietary programming language which the Rosetta translator translates to the industry-standard programming language "C++".
Rosetta Translator--The Tandem Computers Inc. product which will embody this invention. It is named after the "Rosetta Stone", which was a key to translating ancient Egyptian languages.
Scanning--The computer method of examining the text of a computer program one character at a time, recognizing the adjacent groups of characters as tokens.
Scope--The region of program text in which an identifier is recognized to have a certain meaning. For example, a macro formal parameter only has "scope" within the macro body; it is not recognized before the front of the macro definition, nor after its end.
Semantic Analysis--Processing of a syntax tree by a compiler to determine additional information about the program necessary to generate a correct code file for the program.
Shallow In-Order Traversal--In the context of a hierarchical tree structure, a shallow in-order traversal from a node within the tree visits the immediate children of the node in first-to-last order. This ordering is usually represented graphically by placing the child node which is first in order as the left-most child of the node, the next child node immediately to its right, and so on.
Source Code--The program source for a program which is to be translated.
Source File--The computer memory--usually kept on durable media such as magnetic disk--where part or all of a program source is kept.
Source File Inclusion--Programming language construct for specifying that the sequence of tokens contained by a source file named in the construct should be substituted in the program source for the source file inclusion specification. Also, the result of that inclusion.
Source Inclusion Mechanism--The means by which source file inclusion is specified in program source and accomplished by a compiler or preprocessor.
Source Language--The computer programming language in which a program to be translated is specified.
Source Language Text--A program source specified in a source language.
Standardized High-Level Language--A computer language whose definition is in the public domain, specified by one or more official or de-facto standards. There are typically compilers available for standard languages on many brands and models of computers.
Static Fragment--The portion of program source which specifies the sequence of tokens which are to be substituted when a virtual source production mechanism is invoked.
Subtree--A node in a tree, plus all the descendants of that node, plus all their descendants, etc.
Syntactic Construct--A sequence of tokens specifying some computer operation. Examples of constructs include naming of memory locations and performing arithmetic operations on those locations.
Syntactic Construct Boundary--The first and last tokens used to specify the use of a syntactic construct.
Syntax--The rules by which tokens in a program source are interpreted to specify constructs in a programming language.
Target Language--The computer programming language produced by a language-to-language translator such as Rosetta. (The language "aimed at", ergo the "target language".)
Target Language Code--The textual specification of a translated computer program in a target language.
Target Language Output Files--Source files representing a program in the target language. Referred to as "output files" because they are the results (outputs) of the translation process.
Target Language Text--Synonym for target language code.
Target High-Level Language--The computer programming language to which a program is to be translated.
Textual Mismatch--Having one or more characters which are not the same between two fragments at the same relative offset.
Token--A collection of adjacent characters in a program source which forms a single symbol, constant, operator, or punctuation mark.
Translation--The process of rendering a program specified in one programming language into an equivalent program expressed in another programming language.
Translation Session--A single execution of a language-to-language translator; note that a single session may translate numerous source files.
Tree--A directed acyclic graph with a single node identified as a "root".
Tree Surgery--A modification of a valid hierarchical tree data structure to yield another, but different valid hierarchical tree data structure. In the context of this patent, tree surgery is done to interpose encapsulating fragments in fragment trees, or more generally, to interpose shallow-in-order-traversal-reconciliation nodes.
Type Cast--A programming language operation which specifies that an operand of one data type (e.g. integer) should be converted to and treated as being of another data type (e.g. real).
Type Compatibility Rules--Programming language rules (usually enforced by the compiler used) governing how operands of different types (e.g. alphanumeric text, integers, and real numbers) may be used together in operations such as arithmetic, comparisons, and data movement.
Virtual Fragment--The sequence of tokens which results directly from the invocation of a virtual source production mechanism.
Virtual Source--A program's virtual source is the stream of tokens that a compiler parses to create a syntax tree representing the program. Virtual source does not necessarily exist in textual form in any single source file; the token stream is created by a series of macro expansions, macro formal parameter substitutions, and source inclusions.
Virtual Source Production Mechanism--Any of the means of specifying text substitution in a programming language, including source file inclusion, macro expansion, and macro actual parameter substitution. The text resulting from the combination of all such means in a computer program is called its "virtual source", hence the means are collectively called "virtual source production mechanisms".
Yield--In the context of doing a shallow in-order traversal of the children of a node in a hierarchical tree, the "yield" is the sequence of values of interest obtained as each child is visited. In a virtual fragment tree, for example, a shallow in-order traversal from a node representing a virtual fragment would visit the subordinate virtual fragments and tokens which are the immediate descendants of the node. The values of interest for the subordinate virtual fragments would be the text of the invocation expressions for those subordinate fragments; the values of interest for the tokens would be the text necessary to represent the tokens. The overall yield of the traversal would be the ordered text of the invocation expressions and tokens which make up the represented virtual fragment.
A prior art tree data structure is outlined in FIG. 1. The purpose of this data structure is to relate a set of "things" or objects in a hierarchy. One object in this set, called the root node, is at the vertex. From the root, links, called branches, connect to other objects, called nodes. In turn, the nodes may branch to other nodes ultimately terminating in a set of objects called leaves. Viewing the tree from the root to the leaves, tracing a single path of branches, nodes are ancestors of each other. Conversely, viewing the tree from a leaf to the root, again tracing a single path, nodes are descendants of each other. Choosing an arbitrary node, it is considered the child of the node to which it branches toward the root and the parent of the node branching toward the leaves. There are no cycles in a tree; an object is never directly or indirectly its own ancestor.
FIG. 2A, FIG. 2B, FIG. 2C, and FIG. 2D illustrate a contribution of the present invention to the prior art. It is termed "encapsulating tree surgery." Referring to FIG. 2A and FIG. 2B, a first and a second tree are shown. There is a node containing the data item C in the first tree and a second node containing the same data item C in the second tree. The purpose of the tree surgery is to change both the first and the second tree so that a shallow in-order traversal of each yields an exactly corresponding set of nodes. As shown in FIG. 2C and FIG. 2D, this is achieved by:
Removing, but keeping in order and not discarding, the differing subordinates from the first and second nodes;
Creating a subnode with data item M as a child of the first node;
Creating a second subnode with the same data item M as a child of the second node;
Making the differing subordinates which were removed from the first node children of the first subnode; and
Making the FIG. 2A subordinates D and E, which were removed from the second node, children of the FIG. 2C second subnode M.
FIG. 3 is a simplified block diagram of a computer system, designated generally with the reference numeral 50A, incorporating the data structure of FIG. 1. As FIG. 3 illustrates, the computing system 50A includes a central processing unit (CPU) 51A that is coupled to a memory 54A and an input/output channel (IOC) 56A by a bus structure 58A. IOC 56A, in turn, connects the CPU 51A to a data storage area 62A by an input/output (I/O) 60A. The data storage area 62A may take the form of a magnetic disk media storage device, an electronic memory, or a communications link to other storage areas.
As illustrated in FIG. 4, the source code to source code translator of the present invention, in simplified form, generally follows the flow of the translator of the parent application. The primary difference is the additional step of encapsulation while performing consistency checks as depicted by 36a, 36b, 41a and 41b.
FIG. 5 is a flowchart of performing consistency checks of static fragments produced by different translation sessions. A program may consist of a number of files, some of which may be translated during different sessions. All translations must share the same definition of each static fragment; therefore all translations of static fragments must be checked for consistency. The method comprises calculating the differences among fragments, identifying invocation expressions, matching tokens, and encapsulating differing token subsequences.
FIG. 6 is a flowchart of performing consistency checks of virtual fragments produced within a current translation session. Each static fragment of a program source may have many instances, the translation of which are virtual fragments in a target virtual fragment tree. A text rendering of one of these instances (called the reference instance) will become a target static fragment which is the translation of the source static fragment, and must accurately represent all of the virtual fragments which are instances of the target static fragment. Therefore all translations of each static fragment must be checked for consistency; a text rendering of each must be textually the same as the text rendering of the reference instance.
The method shown in FIG. 6 comprises calculating the differences among fragments, identifying invocation expressions, matching tokens, and encapsulating differing token subsequences.
FIG. 7 is a flowchart of encapsulating a token subsequence. It is an implementation of the method of tree encapsulation surgery shown in FIG. 2A, FIG. 2B, FIG. 2C, and FIG. 2D. Control commences at terminal block 680 and immediately flows into function block 681, where the first fragment in which identified tokens reside is acquired. In function block 683, an encapsulation fragment is created which is an instance of the static fragment. Then, in function block 685, an invocation expression for the encapsulation fragment is created. An invocation expression is linked to the encapsulation fragment in function block 687. In function block 689, the identified tokens are removed from the first fragment. In function block 691, the invocation expression is added to the first fragment in the place which was occupied by the removed identified tokens. Finally, in function block 693, the identified tokens are placed in the encapsulation fragment.
FIG. 8 is a simplified example showing two executions of the translator performing consistency checks between two translations of a shared source file. Two source files 701 and 703 are input to translator session 705. The translator session 705 produces a report 707, a translation 709 of source file 701, and a first translation 713 of source file 703. Next, two source files 711 and 713 are input to translator session 715. Translator session 715 produces a report 717, a translation 719 of source file 711, and a second translation 721 of source file 703. Translation 721 supersedes translation 713. That is, translation 721 includes a superset of the valid static fragment translations which were included in translation 713.
FIG. 8 illustrates two invocations of the Rosetta Translator. The first 705 takes "myprog" 701 as a primary input file, which in turn sources in the text file "inc11" 703.
______________________________________pTAL file "incl1"define orchestra(champagne) = (champagne * 2)#;define balcony(beer) = (21 + beer / 2)#;define standing(soda) = (soda + 1)#;pTAL file "myprog"?source incl1proc p;begin int x; x := orchestra(x);end;______________________________________
After the first translation session 705, the macros that the program used have been translated; those that the program has not used have not. The translation session generates a C++-coded "myprog" file 709 and a C++-coded "inch" file 713.
______________________________________C++ file "incl1"#define orchestra(champagne) (champagne * 2)#define balcony(beer)#define standing(soda)C++ file "myprog"#include "incl1"void p { short x; x = orchestra(x);};______________________________________
The second translation session 715 takes a pTAL program file "hisprog" 711 as the primary input file, which in turn sources in the pTAL file "inc11" 703. Because the pTAL file "inc11" has been partially translated, the second translation session 715 takes the C++-coded version of "inc11" 713 as input so that it can perform a consistency check.
______________________________________ pTAL file "hisprog" ?source incl1 proc z; begin int a; a := standing(2); end;______________________________________
After the second translation session 715, the macros that any previously translated program have used have been translated; those that no translated program have used have not been translated. The second translation session generates a C++-coded "hisprog" file 719 and an augmented C++ coded "inch" file 721.
______________________________________C++ file "hisprog"#include "incl1"void z { short a; a = standing(2);C++ file "incl1"#define orchestra(champagne) (champagne * 2)#define balcony(beer)#define standing(soda) (soda + 1)______________________________________
FIG. 9 is an example of a virtual fragment tree. FIG. 10 is a second example of a virtual fragment tree which is an instance of the same static fragment of which the virtual fragment tree in FIG. 9 is an instance. The fragment subtrees in FIG. 9 and FIG. 10 illustrate that the two instances of the macro expansion contain sequences of tokens that do not match textually.
FIG. 11 shows FIG. 9 as modified by the insertion of a ghost formal. Likewise FIG. 12 shows FIG. 10 as modified by the insertion of a ghost formal. The translator adjusts the target language fragment tree in both places to encapsulate the difference in ghost formal parameters. The dashed lines indicate instances of actual parameters.
FIG. 13 is an example of a virtual fragment tree that contains a use of a macro parameter. FIG. 14 is a second example of a virtual fragment tree that contains a use of a macro parameter. The tree in FIG. 13 and the tree in FIG. 14 are instances of the same static fragment. The fragment trees in FIG. 13 and FIG. 14 illustrate two instances of a macro expansion that contain sequences of tokens that do not match textually. Furthermore, the mismatching tokens in each example match the tokens encapsulated in the existing macro formal use fragment that is subordinate to the macro expansion fragment.
FIG. 15 shows FIG. 13 after it is modified by inserting an additional use of the existing macro formal parameter, sname. Likewise, FIG. 16 shows FIG. 14 after it is modified by inserting an additional use of the existing macro formal parameter, sname. The translator adjusts the target language fragment tree in both places to encapsulate the difference in an additional use of the existing parameter.
FIG. 17 is the same as FIG. 11. A macro formal parameter use has been inserted into this tree to encapsulate the textual difference between this first instance of this macro expansion and a second instance of the expansion of the same macro. FIG. 18 shows a third exansion of the same macro. The sequence of tokens in the macro expansion fragment illustrated in FIG. 17 do not match the sequence of tokens in the macro expansion fragment illustrated in FIG. 18. In particular, the token "stype" in FIG. 17 is not textually identical to the token "h-- " in FIG. 18. Because the tokens in the first differing subsequence ("stype") represent a fragment invocation, the tokens in the second differing subsequence can be encapsulated in a new instance of the fragment that the first subsequence of tokens invokes. This transformation is called propagating the encapsulation to a new fragment. FIG. 19 shows the fragment from FIG. 18 after the encapsulation.
While the invention has been described with reference to a specific embodiment, the description is not meant to be construed in a limiting sense. Various modifications of the disclosed embodiment, as well as other embodiments of the invention, will be apparent to persons skilled in the art upon reference to this description. It is therefore contemplated that the appended claims will cover any such modifications or embodiments as fall within the true scope of the invention.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
Cats Do The Dumbest Things
Stolen Car Returned To St. Louis Owner Pimped-Out and Painted
25 Things You Probably Google When You're All Alone
15 Banned Baby Names from Around the World
10 Most Gorgeous Airline Flight Attendants
5 Popular Houseplants That Actually Purify Your Air
31 Neighbors You Do Not Want To Live Next To
Controversial "Limitless Pill"
18 Cute Girls Gone Ugly
14 Most Bizarre Medical Conditions on Earth
10 Most Intense Body Parts
Look What This Husband Does To The Belly Of His Pregnant Wife
30 Completely Absurd Russian Dating Site Photos
Watch These Amazing Kitchen Hacks That Will Definitely Make Your Life Easy
What The Rich Babes of Instagram Look Like
16 People Fortunately Saved from Their Horrible Tattoos
13 Photos That Shouldn't Have Been Taken
43 of The Most Magnificent Photobombs Ever Captured
10 Rad Inventions You're Gonna Want to Buy Right This Second
46 Perfectly Timed Photos You'll Have to Look Twice to Understand.
12 Terrifying Truths About The North Korean Dictator
45 Idiots Who Picked Fights with the Wrong Guy
The 5 Smartest People of All Time
It's The Simple Things In Life: 29 Life Hacks
30 People Who Should Learn How Mirrors and Reflections Work
The Rolls-Royce Even Millionaires Can't Touch
Top 25 Dumbest, Most Overrated Car Accessories
12 Real People Who Look Just like Cartoon Characters
6 Architectural Illusions that Will Simply Blow Your Mind
AHHH! 13 Bone Chilling Pictures of Horrifying Hell Beasts

subset: commoncrawl


text:
Stonesoft Oyj : SUBSCRIPTION PRICE AND MARKET VALUE OF STONESOFT CORPORATION STOCK OPTIONS 2012B Stonesoft Corporation Stock Exchange Release April 3, 2013 at 9:59 a.m. SUBSCRIPTION PRICE AND MARKET VALUE OF STONESOFT CORPORATION STOCK OPTIONS 2012B The Board of Directors of Stonesoft Corporation decided on 18 January 2012 based on the authorization by the Annual General Meeting of Shareholders on 13 April 2011 about the issuance of stock options to Stonesoft Group key employees. The share subscription price for stock option 2012B is EUR 2.31 per share (the trade volume weighted average quotation of the share on NASDAQ OMX Helsinki Ltd during 1 February-31 March 2013). Annual dividends and equity returns are deducted from the share subscription price. A total of 1,500,000 new shares or existing shares held by Stonesoft Corporation can be subscribed for with stock options 2012B. The share subscription period for stock options 2012B will be 1 March 2016-31 March 2018. The share subscription period will only begin if the Net Sales in consolidated financial statements of any financial year 2012-2016 is at least forty-two (42) million Euros. The stock options for which the target has not been attained will expire in a manner decided by the Board of Directors. The theoretical market value of one stock option 2012B is EUR 1.07. The theoretical market value of the stock options 2012B is EUR 1 605000 in total. The theoretical market value of one stock option has been calculated based on the Black-Scholes stock option pricing model with the following input factors: share price EUR 2.20, share subscription price EUR 2.31, risk free interest rate 1.8%, validity of stock options five years and volatility 57%. The terms and conditions of the Stock Options 2012 are available on the Company's internet pages www.stonesoft.com. Stonesoft Corporation Ilkka Hiidenheimo Chief Executive Officer For further information, please contact: CEO Ilkka Hiidenheimo, Stonesoft Corporation Tel. +358 9 4767 11 Distribution: NASDAQ OMX Helsinki Ltd www.stonesoft.com ------------------------------------------------------------------------------ This announcement is distributed by Thomson Reuters on behalf of Thomson Reuters clients. The owner of this announcement warrants that: (i) the releases contained herein are protected by copyright and other applicable laws; and (ii) they are solely responsible for the content, accuracy and originality of the information contained therein. Source: Stonesoft Oyj via Thomson Reuters ONE HUG#1689727
Stonesoft Oyj : SUBSCRIPTION PRICE AND MARKET VALUE OF STONESOFT CORPORATION STOCK OPTIONS 2012B
Press spacebar to pause and continue. Press esc to stop.


text:
Hospital Records Manager: Job Description and Career Information
Learn about the education and preparation needed to become a hospital records manager. Get a quick view of the requirements as well as details about degree programs, job duties and voluntary certification to find out if this is the career for you.
Essential Information
Hospitals rely on accurate patient records in order to deliver quality care and ensure that both patients and insurers are billed properly. A hospital records manager makes sure that information is compiled accurately and that appropriate steps are taken to ensure patient confidentiality. A bachelor's degree in health information management or a related field is generally required, and voluntary certification is available.
|Required Education
|Bachelor's degree
|Other Requirements
|Voluntary certification
|Projected Job Growth (2012-2022)*
|23% (for all medical and health services managers)
|Median Salary (2013)*
|$90,940 annually (for all medical and health services managers)
Source: *U.S. Bureau of Labor Statistics
Hospital Records Manager Job Description
A hospital records manager oversees databases and ensures the security and privacy of patient information. According to the U.S. Bureau of Labor Statistics (BLS), records managers must be competent with computers in general as well as with specific filing and database software (www.bls.gov). Because medical facilities might use a proprietary electronic records management system, some training might take place on the job. Hospital records managers also must be able to monitor regulatory and legal changes in laws regarding patient record compilation and storage.
Educational Requirements
To work as a hospital records manager, an individual usually needs to hold a bachelor's degree in health information management from a program accredited by the Commission on Accreditation for Health Informatics and Information Management Education (CAHIIM). Another option is to complete a CAHIIM-accredited post-baccalaureate certificate program in health information management. Master's degree programs in health informatics or information management can qualify graduates for advancement in the field.
Professional Certification
While it's not required to work as a hospital records manager, professional certification can increase an individual's employability in the field. The American Health Information Management Association (AHIMA) offers the Registered Health Information Administrator (RHIA) and Certified in Healthcare Privacy and Security (CHPS) credentials. The latter is intended for records managers who are interested in information security compliance.
Career Outlook and Salary Information
According to the BLS, the median salary for medical and health services managers was $90,940 as of May 2013. However, both the BLS and AHIMA note that salaries can vary significantly according to a hospital records manager's job level as well as the type of facility in which he or she works. The BLS indicated that jobs in health services management were expected to increase by 23% from 2012 through 2022.
Related to Hospital Records Manager: Job Description and Career Information
- Related
- Recently Updated
- Popular
Medical Records Manager: Job Description, Duties and Requirements
Learn about the education and preparation needed to become a medical records manager. Get a quick view of the requirements as...
Medical Program Manager: Job Description and Salary Information
Learn about the education and preparation needed to become a medical program manager. Get a quick view of the requirements as...
Medical Laboratory Manager Career Info
Explore the career of a medical laboratory manager. Learn about the duties, training, job outlook and salary to see if this...
Medical Information Manager: Job Duties & Career Requirements
With a bachelor's degree in health information management and professional certification, experienced medical records...
Top School in Columbus, Ohio, for Becoming a Medical Office Manager
- Schools with Medical Information Management Degrees and Classes
- Medical Office Manager: Job Duties & Career Requirements
- Hospital Manager: Job Description & Career Requirements
- Digital Photo Editing Training and Education Program Information
- Interior Design: Diploma Summary
- Masters in Retail Management: Program Information
- Doctorate in Health Law: Degree Information


text:
STEVENS TOWERS Apartments930 Willow St, Lebanon, PA 17046 View On Map (717) 273-1639
For rates, availability, and other information fill out the availability request form and a representative from STEVENS TOWERS Apartments will contact you shortly
Stevens Towers is located in the Harrisburg Area in the 17046 zip code. View this apartment on a map.
Back to Top
Maps & Directions
click to view interactive map


text:
To embed, copy and paste the code into your website or blog:
On Sept. 16, 2011,a federal judge in Miami sentenced Lawrence Duran to 50 years in prison, the longest sentence ever imposed in a Medicare fraud case, for his role in a massive fraud scheme that resulted in more than $205 million in losses. Duran was also ordered to pay $87 million in restitution.
Duran was co-owner of American Therapeutic Corporation with Marianella Valera, his girlfriend. Both of them pleaded guilty in April to fraud, money laundering, and conspiracy charges after being arrested in October 2010. In their pleas, Duran and Valera admitted that they executed the scheme from 2002 until their arrest in 2010. A total of 34 people, including employees of American Therapeutic, doctors, and nurses were arrested in connection with the scheme.
Please see full article below for more information.
Firefox recommends the PDF Plugin for Mac OS X for viewing PDF documents in your browser.
We can also show you Legal Updates using the Google Viewer; however, you will need to be logged into Google Docs to view them.
Please choose one of the above to proceed!
LOADING PDF: If there are any problems, click here to download the file.
DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.
© Jeff Ifrah
Read fresh new writing on compliance, cybersecurity, Dodd-Frank, whistleblowers, social media, hiring & firing, patent reform, the NLRB, Obamacare, the SEC…
…or whatever matters the most to you. Follow authors, firms, and topics on JD Supra.
Create your news brief now - it's free and easy »
Hands-on Counsel, Gloves-off Litigation
When the government comes knocking, clients turn to the...
View Profile »
See more
Sign up for your custom alerts now, using LinkedIn ›
Back to Top
Copyright ©


text:
Shane Warne and his googlies are as inseparable as whiskey and ice. The 'Sheikh of Tweak' added more twist to MS Dhoni's categorical demand for rank turners.
On Thursday, ESPN-Star Sports included the Aussie great on its commentary panel for the second Test starting on Friday. Warne, dressed in a pink (of all colours!) sweater promised to make your viewing experience even more special. What's more, he will be back for the India-Australia series too in the New Year.
Back to his googly and Warne first said he wouldn't approve of captains asking for specific pitches. "I don't think the captain should be asking. It should be up to the groundsman. The groundsman will take pride in producing the best Test wicket. In Australia, captains never approach curators," Warne said, in reference to a query on Dhoni. "There is a contest between bat and ball. I don't think anyone is interested in flat wickets with 700 runs. It's boring. But in India you have to expect turning wickets."
A little later, 'Warney' did a U-turn. In response to a question on similar lines, he said, "You know it's red soil. You know it is going to spin. I think Dhoni is playing a few mind games with the England batsmen. I am sure he hasn't even spoken (to the curator). He is just trying to put some doubts in the English batsmen's mind that they are going to get huge turning wickets. But I am sure the pitch will be just the same. It is just mind games."
Let's wait for the pitch report.


text: Not that this will come as much of a surprise to anyone at this point, but Samsung and Verizon have finally announced their intent to sell an LTE-compatible version of the Galaxy Camera on Big Red's network starting this Thursday for $549.99. Interestingly, there was no mention of when or if the TouchWiz-running camera will show up in stores, but you can at least pick one up in either white or blue through the carrier's website. If you choose to grab one and take advantage of the faster data, Verizon's offering a promotion in which you only have to tack on an extra $5 per month to your Share Everything plan. Not a bad deal, considering a tablet will run you twice that. Read the full story at Engadget.


text:
Forgot Password? | Not a User? Sign up
Your browser does not support iframes.
Last week, I had the privilege to represent the Beacon at the General Federation of Women's Clubs-South Brunswick Islands' "A Night of Benevolence — Caring for Our Community" at Shallotte Presbyterian Church.
I have to admit I hadn't planned on attending — it took place April 27, the night before our production day when deadlines for the week's next edition bear down on us — but the group's president, Cindy Hewett was insistent. I'm glad I went.
Robert Stern knows the intricacies of living in a gated community.
After all, he resided and served on the board in one of those exclusive enclaves ruled by a homeowners association (HOA) back in Henderson, Nev. Locally, Stern owns another house in Ocean Ridge Plantation, another HOA-POA community.
A few years ago, through his HOA residency and involvement in the Silver State, Stern found himself embroiled in legal battles with what he deemed power-hungry board members who summoned their lawyer when he questioned their modus operandi.
This week we debated and passed at least two very controversial bills on judicial elections and abortion; we passed a record number of bills out of committees and directly onto the House floor; and we put in the longest days of the session so far, going more than 14 hours.
The week started off in Raleigh very warm, but turned cooler as the days went on. The attitudes of the legislators were also hot and cold, depending on whether our bills were getting passed.
By Dr. Mike Walden
Guest Columnist
The economic world doesn't treat everyone and everything equally. We clearly see this in the ongoing debates about income inequality, CEO pay, the minimum wage and taxes. Another way we see this is in economic geography. For example, in North Carolina, for several decades we have watched urban counties adding jobs and incomes at a much higher rate than rural counties.
To the editor:
I read with shock and dismay that Sunset Beach has spent more money than revenue received in all but one of the last five years. The town is now proposing a 60-percent tax hike. I assume this outrageous increase being proposed will be cut to 30 percent by town council, who will tell the taxpayers what a good job they are doing. A 30-percent increase is not a good job! Continuously spending more than you take in is not a good job. Continuously telling the public that finances are in good shape when obviously they are not is not a good job.
To the editor:
To the editor:
Last year, Sunset Beach Town Administrator Susan Parker recommended a 31-percent tax rate increase. The council and mayor gave the impression the town's fiscal problems were not as serious as proclaimed by Parker. To prove this point, not one agenda item was devoted discussing her alarming proposed tax rate increase. Mayor Ron Watts even claimed in the Beacon "the town is financially strong."
To the editor:
On April 15, Brunswick Family Assistance (BFA) hosted a breakfast program to honor and salute volunteers for their dedication and hard work. We would like to recognize publicly to all Brunswick County residents the passion, dedication and community service of our volunteers. BFA is very fortunate to have 87 volunteers who dedicate their time, talent and expertise to provide assistance and services to our neighbors in financial crisis.
Copyright © 2015
The Brunswick Beacon is your source for local news, sports, events and information in Brunswick County, North Carolina and surrounding areas.


text:
Research Output for John Senior
Note: The 2012, 2013, 2014, 2015 publications have not been audited.
Jump to: Publications | Grants and Consultancies | HDR completions
John Senior may be from another institution or only recently joined Deakin University.
2003 External
Senior, John* and Townsend, Mardie (2003) "Healthy parks, health people" and other social capital initiatives of Parks Victoria, Australia, in Trzyna, Ted (eds), Urban Imperative, Urban Outreach Strategies for Protected Area Agencies: Proceedings of a workshop at the Vth IUCN World Parks Congress, pp. 111-120, InterEnvironment/California Institute of Public Affairs, Sacramento, Calif. [E1.1]
DRO entry for this publication
Grants and Consultancies
All years
Research Income - National Competitive Grants
Townsend, M, Gullone, E, St Leger, L, Senior, J, Brown, P and Haining, V. Living high but healthy: impacts of access to nature on inner city highrise residents' health, wellbeing and effective functioning, Australian Research Council Linkage APAI [T]
- 2005: $24,650
- 2004: $24,148
- 2003: $23,578
- 2004: $7,500
- 2003: $7,500
- 2006: $12,426
- 2005: $7,500
Higher Degree by Research Completions supervised by John Senior
No completions found or audited.
- Legend:
- * Not a member of Deakin University at time of output.
DRO to publications collection last synchronised: Friday 29th May 2015 10:04pm


text:
Apple Changes OS X's Main Font For The First Time Ever
Following the lead of iOS, Apple's desktop operating system says goodbye to Lucida Grande, and hello to Helvetica Neue.
Since the introduction of OS X in 2001, Lucida Grande has served as its main system font. But after taking the wraps off OS X 10.10, aka Yosemite at today's Worldwide Developers Conference, it looks like the operating system's new system font is going to be Helvetica Neue.
Apple didn't call out the font by name, but it bears very close resemblance to what's used in iOS 7, and that's Helvetica Neue.
The move isn't completely surprising. Helvetica Neue has served as the main iOS font since last year, and one of the main objectives of the latest OS X update is to bring it closer in line with Apple's mobile platform, both functionally and visually.
What does this mean? A lot of the basic areas where you interact with OS X—folders, windows, menu bars, etc.—will look a little different. And how does this new font work in OS X? We still haven't seen enough of the new OS in action to say, but it's worth noting that Helvetica Neue's implementation in iOS 7 has drawn mixed reactions (namely, the font can be hard to read on the smaller iPhone screen).
Read more on Apple's WWDC keynote.
[Image: Mac screen via bloomua / Shutterstock]
Add New Comment
12 Comments
Not entirely sure why the company is taking so long to design Apple Sans, or if they shelved the idea, why. Hopefully Helveltica Neue is a stop-gap measure that they are using because it's cheap to license until they can deploy Apple Sans. It definitely has major issues with readability at small sizes that cannot be resolved by higher resolution displays. It is the letterforms themselves that cause these issues.
I was infatuated with Helvetica Neue in 2009. Its basic utility, however, makes it a little over used these days, so we might as well go all the way. Maybe designers will be challenged to seek out a good alternative to it. I was once infatuated with Archer, too—at least they're not using that font.
Helvetica Neue can work well on retina screens, where smaller shapes can still remain legible. Maybe this heralds the end of non-retina screens produced at Apple? That would imply the Air, the iMac and the Thunderbolt Display would need updated. We already know that Apple needs to produce a 4k display for the Mac Pro, so I expected a Retina replacement for the Thunderbolt this year (and it makes sense that the iMac would use the same).
Even on a higher resolution display, readability of a word like milliliter at a small points size in Helvetica Neue can be next to impossible, because of the letterforms themselves. There's just not enough of a distinction between the i, I, l, L, letterforms.
$137B in cash and they can't be bothered to develop a font from scratch for their OS...
But they'll spend $3B on Beats by Dre...
I like Helvetica, but it was never developed for the digital age, and is heavily overused by designers (I should know I am one and guilty of using it from time to time).
At least Microsoft attempted to create fonts for the digital age (Calibri and Cambria).
Yeah man, who told these guys Helvetica Neue was in any way intended for < 150 dpi screens? Also, who told them it would be effective on even retina screens? Helvetica works great as a display font and small blocks of text, but its need of white real estate for good legibility is far from optimal for a user interface. With so many great Helvetica-based, more humanist typefaces, Jony Ive should've been to one of them Typography 101 classes Steve Jobs famously attended as a drop-out to meet a couple of good alternatives (Avenir being the other miscast on their collection nowadays — great font on paper for information graphics, e.g., it's too scattered when used in such dynamic arrangements as the ones found in UI)… Hell, Lucida Grande was a great compromise before this. I know it looks poor on retina screens but it was closer to what a screen Ui font needs to be. Helvetica's metrics are just not for this, imo.
When in doubt, listen to Spiekermann (turn on english captions if you don't speak german) : http://www.youtube.com/watch?v=Sw0syzCeH4Q
It is surprising because of its illegibility as a screen font, especially at small sizes where it is already difficult to recognize i l and I. In neue they look more alike: even regular Helvetica would be a better choice. The closer kerning in neue is tiring for the eyes.
I think the result will be a diffuses largeness in the menu, helvetica has a different spacing than lucida!
Massimo would approve
Helvetica for life.


text:
- Show:
- Comments
- Liked Comments
On Did Your Parents Lie About Your Age To Get Lower Ticket Prices, And Did That Scar You For Life?
My mom once borrowed her friends pool passes while we were staying with my grandparents one summer. She joked that if anyone asked my name was Becky. I was TERRIFIED some one would ask my name and so I hid in the kiddie pool all day.
On The Billfold Book Club: Elizabeth Gaskell's 'North and South' (Chapters 1-25)
@HelloTheFuture Edith is basically Becky Bloomwood I think. Totally self-centered and shallow, and everything works out for her. She is pretty silly but also I wouldn't mind having her life?
On The Billfold Book Club: Elizabeth Gaskell's 'North and South' (Chapters 1-25)
@Marille I guess I just meant that in Milton, no one knows her mother's family, and her father is just a poor tutor. In the same way that Margaret had never heard of Mr. Thornton before moving to Milton, despite Mrs. Thornton's belief her son is famous among businessmen, no one has heard of the Hales in Milton. I would totally snub the hales if I were a Milton mill owners sister. Also, all the Hale's except Margaret are the worst--so selfish and mopey!
On The Billfold Book Club: Elizabeth Gaskell's 'North and South' (Chapters 1-25)
I feel a little bit like Betsy writing her essay on Ivanhoe, harping on the beginning chapters. But one thing that stood out in this reading is that Margaret is very much a poor relation--she is more like Fanny Price than Elizabeth Bennett. She is genteel without any wealth or family on her father's side, and even that genteelness is kind of lost when Mr. Hale leaves the church. I am kind of with Mrs. Thornton in thinking Margaret seems high and mighty. I read this book originally because of the mini-series, because Margaret + John 4eva, and was so disappointed on first reading with all the capitalist and religious conversations you have to slog through before you get to the parts where Margaret and Thornton are thinking of each other. Anyway, I do money like cousin Edith, and not like any of the actually admirable characters in this book.
On Let's Throw Some Money at Our Problems: December 2013 Check-In
On Let's Throw Some Money at Our Problems: December 2013 Check-In
I paid off my credit card! it was at about $600 at the beginning of December, when I started a new job, and I used my double paychecks in December(one from the old and one from the new job) to pay it all off! Next I am working on a student loan serviced by Nelnet, and also saving money for a trip to New York in the fall.
On Friday Estimate
@LookUponMyWorks I guess I just miss the glory days of paying $45 for a full price sweater, and less if it was on sale, instead of crossing my fingers that the sweater I wanted was still available while waiting for it to be discounted to $45 from $90. Their prices have gone way up in the past 4 years.
On Friday Estimate
@LookUponMyWorks What is up with LOFT's prices? Their sale prices used to be way more affordable.
On Friday Estimate
I am going to TWO Origami Owl parties, and I want to support my friends and independent women who unfortunately work for pyramid schemes, so I will probably spend about $150 on necklaces, and then Old Navy is having a sweater sale, and I need some sweaters for my NEW JOB that starts after Thanksgiving. "Need". $200?
On Big Food Is Coming For Us
@cuminafterall Unless you live in an area with a really strong recycling program, bags and boxes are non-recyclable--even tetra pak. My community can handle recycling cans, but can't recycle yogurt cups, let alone tetra pak. That said, my husband is all over Campbell's chili in a bag.


text:
10 Things You Need to Know About Zac Efron
Credit: Pacific Coast News
5 of 10
5. Zac was supposed to star in the 2011 Footloose remake but dropped out after talking to Tom Cruise! Zac starred in the High School Musical films, as well as Hairspray, and because of that he didn't know if he wanted to do another musical. So, after talking with Tom, and getting advice from others, Zac decided not to do Footloose. Can you imagine him and Julianne Hough in that movie though? That would've been amazing!
Tags: Zac Efron


text:
As well as my formal education in philosophy, theology, psychology and the humanities...I have an extensive background in fine arts, theater and event work! You will discover the importance of this background experience when I assist in guiding you through decisions and details concerning the orchestration of your wedding day...details that make all the difference in your comfort and freedom from stress! My services are all inclusive and assure the best of care and calm on your wedding day!
Your Wedding Ceremony will set the tone for your entire day and night of celebration! You get to decide exactly what sort of tone you want to create! You can be sure that I will take the time to understand your story and personalities and find the perfect balance of language and tone...I will create your Custom Wedding Ceremony that shares what you would like to say and how you feel. The perfect expression for the two of you and for your guests too!
The majority of the couples I work with are non-denominational. Often a couple does not belong to any religious congregation. Many may have been brought up with a particular denomination but they have chosen not to follow in the footsteps of that faith tradition. We can work together to find the perfect language that bridges spiritual sensibilities and speaks for your understanding of life, love, truth and spirit.
Your perfect Wedding Ceremony, which symbolizes your love and commitment to one another, is the beginning of a great celebration. Your ceremony marks the beginning of a new phase of life that you will continue to create together for years to come. Your marriage ceremony can personally reflect your story, your unique moment of saying "I Do." and can include your hopes and aspirations for the future too.
All of the information you need on fees and process is found ...on the Custom Ceremonies & Fees page!