|translating C to Java language zahir@senan.Eng.Sun.COM (1996-12-01)|
|Re: translating C to Java language firstname.lastname@example.org (1996-12-03)|
|Re: translating C to Java language email@example.com (1996-12-07)|
|Re: translating C to Java language firstname.lastname@example.org (1996-12-15)|
|From:||email@example.com (S.Bharadwaj Yadavalli)|
|Date:||7 Dec 1996 23:07:07 -0500|
|Organization:||University of Saskatchewan|
Kindly note: I am NOT an OO expert but am posting this more as
an effort to clarify my comprehension of the concepts. I may be
over-simplifying things but only to get to the fundamentals
rather than to trivialize issues involved.
firstname.lastname@example.org wrote in reply to zahir@senan.Eng.Sun.COM's query:
: > Has any one looked at writing a semantic translator from a C language
: > description to a functionally equivalent Java language description?
: > The translation need not be entirely automatic, human interaction in
: > the conversion cycle for corner cases might be okay with a proper
: > environment assist.
: > Has anyone done a similar translator from C to another object
: > oriented language?
: But C is not object oriented. I always see the job of translation
: as maintaining the structure of the original code. So no object
: oriented code in, no object oriented code out.
But what is so *fundamentally* different with object-orientation
in comparison to modular / procedural nature of, say, C? Isn't
OO a restructured packaging of the modular / procedural style?
By this I mean the following:
A typical C program structure is as follows:
(optional) global variables
function1((optional) formal parameters to pass info.)
(optional) local variables
a bunch of calls to user defined or system functions;
functions with similar structure as above
Of these functions one of them is designated as "main" to indicate the
entry point to the program.
In an object-oriented program, we just collect together the data items
(variables with "enhanced functionality"?) and functions that operate
upon them and call it a class. (An instance of a more "powerful"
structure with enhanced semantics -- gist of what I read
somewhere). The entry point is designated by a "root" (or whatever)
class. This type of restructuring of modularity opens up opportunities
for conveniences like polymorphism, inheritence and so on. But
fundamentally, I still can not see how OO is semantically different
from procedural / moduler style of programming.
: > Pointers to references or to earlier usenet threads on this topic
: > will be appreciated.
: Eight years ago we wrote a C to Pascal Translator. We also have a
: design for C to Ada (www.knosof.co.uk/ctoa.html). Java
: ought to be relatively easy in some way, but much harder in others.
Given this "repackaging view" OOP seems to be a move towards program
specification at a higher level of abstraction (more closer to human
mind's abstraction than that of the processor), in my view. (Designing
languages closer to human abstraction levels seems to be the goal in
all the programming language design efforts with a few backtrackings
and forward leaps on the way. That is ofcourse besides the point now).
Thus, translation from C (a language closer to the machine than to
human abstraction levels) to an OO language (a language relatively
farther to the machine but also closer to human abstraction levels)
seems to be difficult when compared to a translation the other way
around -- particularly because, it might involve complicated static
analysis to figure out semantically related functions/procedures (or
methods?) and the variables (data items?) being manipulated by
them. Further, sheerly in terms of performance of the resulting
executable, I wonder if it would be helpful at all. If human
comprehension of a program is the goal, such an exercise may be of
Constructive comments are welcome.
Return to the
Search the comp.compilers archives again.