Re: Aspects of programming languages in common

From: James Harris (no.email.please)
Date: 04/27/04 

Date: Tue, 27 Apr 2004 22:55:16 +0100

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns94D7C5AA3FD60jimmaureenrogers@204.127.36.1...
<snip>
> You have some challenges. For instance, if you encounter the expression
>
> if (sum = a + b)
>
> which language is this? Is it good Pascal or bad C? This is, of course,
> legal in C, it just does not mean the same as
>
> if (sum == a + b)
>
> I do not even want to see code such as
>
> total := adding A to B.
>
> mixing Pascal and Cobol. How would you handle the differences in type
> definitions between Pascal and Cobol for this expression? Will you
> provide some kind of automatic conversion between data representations
> in such a mixed language expression? What kinds of assumptions will you
> need to use for such automated conversions?

My thought is that the parser would only recognise one set of constructs at a given point.
For example, if expecting C it would treat the equals sign as assignment, if scanning
Pascal treating := as assignment and = as a comparison. I hadn't thought of this changing
part way through a statement. I agree that this looks horrible.

I /was/ thinking of symbols defined in one language being usable in another. This is
fairly key so that a data structure (or set of scalars) could be defined once, in one
language, this definition to be sharable by other modules which could be written in a
different language but still make meaningful references to elements of that data
structure.

Would that last point address the differences you mention between Pascal and Cobol? (ie
the addition/assignment statement being in one language but the variables being declared
in the other).

The second question about the automatic conversion: again, each expression would be in
just one language. I think that the data types would have to match - so there is no
unnecessary conversion. Do most languages cater for similar scalars such as integers,
reals, strings of various precisions etc.?

The third point about conversions: again, no conversion anticipated, promotions to follow
the normal rules for that language. Does that cover it? 

--
Thanks for the queries. Always useful to have something specific to challenge the idea.
- James

Relevant Pages

  • Re: Aspects of programming languages in common
    ... For example, defining a ... > translator for any mainstream language and, as you mention, allowing ... > embedding such as mainly Pascal source to contain some Cobol ... provide some kind of automatic conversion between data representations ...
    (comp.programming)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)
  • Re: COBOLs Influence on C
    ... Cobol is the only language that has this problem. ... sure that the libraries containing ANYTHING that might be called are on ... And that is one reason why installations have Local Standards... ...
    (comp.lang.cobol)
  • Re: Java is becoming the new Cobol
    ... """If you're a Java developer, now's the time to invest in new ... It is even truer for COBOL developers. ... The question then is: Is Java just another fad language in the range: ... Sometimes it appears they'll use whatever the Fad Language Of The Month Club sent last ...
    (comp.lang.cobol)
  • Re: Wang COBOL alive and well as Wang VS makes a comeback
    ... I fought to the last to keep COBOL at least peripherally in the ... will be the next language du jour... ... This contributes to the stability of programming efforts ... level of COBOL to another can be as big a deal as migrating across platforms ...
    (comp.lang.cobol)