Re: Aspects of programming languages in common

From: James Rogers (jimmaureenrogers_at_att.net)
Date: 04/28/04 

Date: Wed, 28 Apr 2004 04:21:39 GMT

"James Harris" <no.email.please> wrote in
news:408ed6b8$0$31671$fa0fcedb@lovejoy.zen.co.uk:

> 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.

That does sound like a reasonable restriction.

>
> 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.
>

You do have the problem that similar abstractions are implemented
differently in different languages. For example, arrays are not real
types in C. An array variable is a pointer to an address representing
the beginning of a contiguous block of memory.

Pascal arrays much different. Pascal allows array types.
Pascal arrays are associated with size information wherever they are used.

> 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.?
>

Not in all cases. C strings are simply arrays of characters with
a null character indicating the end of the string data, but not
necessarily the end of the array. C++ shares the C definition of
strings. Few other languages treat strings in such a manner. Most
languages have a real string type.

The problem here is that a Pascal string will not necessarily have
the null character at the end of the data. A C string will. A C
program using a Pascal string will never properly recognize the
end of the string. A C program will need to append null characters
to the end of a string. A Pascal program has no such need.

In fundamental ways C and Pascal strings are different data types.

Note that a C string is not a scalar.
Similarly, C has no built-in equivalent for a Cobol packed
decimal data type.

C has no boolean type. Ada has a boolean type which is not
a numeric type. In Ada you can declare a packed array of
boolean and have each array element mapped to a single bit.
C has no equivalent type.

C allows you to create unresolved forward type references.
Ada does not. How would you translate a C unresolved forward
type definition into valid Ada code?

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

Promotion rules differ from one language to the next. This can cause
unexpected results when mixing data types and code blocks from
different languages.

More than that, how will you encode a particular language's
promotion rules into your universal intermediate representation?

Similarly, different languages have different scoping and
visibility rules. How will you represent and resolve such
differences in your intermediate representation?

Jim Rogers

Relevant Pages

  • Re: Aspects of programming languages in common
    ... >> scalars) could be defined once, in one language, this definition to be ... For example, arrays are not real ... > languages have a real string type. ... > In fundamental ways C and Pascal strings are different data types. ...
    (comp.programming)
  • Re: c / c++ : is it end of era ?
    ... You have to scan the whole string first ... has taken the trouble to learn the language. ... This is not a bug, ... array, however, is converted into a pointer to the array's first element ...
    (comp.lang.c)
  • Re: Which is better - a char type or a string of length one?
    ... character long) we could, perhaps, get the first element of each as ... different from a fixed length string? ... That makes your language untyped (or ... means an array of elements, an ordered set. ...
    (comp.lang.misc)
  • Re: left$, mid$ and right$ (was: ANN: pldev.org)
    ... access the characters in the string based upon their positions as an array ... What is it that in that example makes you think "that such a language" isn't ...
    (comp.lang.misc)
  • Re: puzzling error
    ... p then points to the string rather than being an array initialised by ... makes p an array whose contents you're not permitted to modify. ... you have to understand the language well enough to *know* it. ... that the compiler won't complain about, ...
    (comp.lang.c)