Why did other high-level languages not implement COBOL's `CORRESPONDING` keyword?

Question

My first co-op job in university involved programming in COBOL. I later learned many other languages and have never used COBOL since, but its one feature I remember (and miss) most is the CORRESPONDING keyword.

It could be used in three ways:

MOVE CORRESPONDING INPUT_RECORD TO OUTPUT_RECORD
ADD CORRESPONDING INPUT_RECORD TO OUTPUT_RECORD
SUBTRACT CORRESPONDING INPUT_RECORD FROM OUTPUT_RECORD

The RECORDs can be considered the equivalent of a C structure or a JavaScript object:

01 INPUT_RECORD.
   05 ID     PIC XXXXX.
   05 VALUE  PIC 999V99 PACKED DECIMAL.
   05 COUNT  PIC 999.
   05 DATE   PIC …

01 OUTPUT_RECORD.
   05 THING  PIC XXX.
   05 COUNT  PIC +(3).9(2)E+99 NATIONAL.     [*floating point*]
   05 OTHER  PIC 999.
   05 VALUE  PIC 999999V99.
   05 MORE   PIC 9999.

With a single statement, all the fields that have the same name in INPUT_RECORD and OUTPUT_RECORD are processed (only numeric fields are considered for ADD and SUBTRACT).

In this case, only VALUE and COUNT are processed.

The data is also converted as necessary (e.g. VALUE could be floating point in one record and packed-decimal in the other, or strings could be different lengths and require padding).

That one line could potentially require hundreds of lines of code in other languages, and in the future, that code would have to be modified whenever fields are added or removed from either record.

The amount of coding and debugging time saved was incredible.

Why did other high-level languages written since COBOL decide not to include a similar operation?

Answer 1

Because of Types and Composition

I would say the reasons include because we have types and composition.

Type X is different from type Y. To assign a value of type X to a value of type Y successfully needs more than just copying the corresponding fields. So "corresponding" does only part of the job.

struct X
{
   alpha: int
   beta: int
   gamma: int
}

struct Y
{
   beta: int
   gamma: int
   delta: int
}

So you can copy beta and gamma because they correspond. Great! but what about alpha and delta?

COBOL doesn't have proper types it has copybooks Though there are OO variants now that do.

So to copy a structure you had to do something like your move corresponding. Many languages will auto generate copy constructors for plain old data types.

So the syntax given:

 var foo: X;
 var bar: X;

is just:

 foo = bar;

Much more concise and with tighter semantics than "move corresponding".

Finally we have composition. If the corresponding fields are important why not extract them into a dedicated type:

struct Common
{
   beta: int
   gamma: int
}

struct X
{
   alpha: int
   common: Common
}

struct Y
{
   common: Common
   delta: int
}

Now you can write:

foo.common = bar.common

Inheritance works similarly.

Answer 2

Because it's simple to do yourself and there's not much use for it

So, it might save a lot of code in a language like COBOL, but in languages like Python it's actually just a one-liner:

[(v, y.__dict__[k]) for k, v in x.__dict__.items() if k in y.__dict__]

(Attempt This Online!)

Because of this, it doesn't really make sense to make a built-in for it in languages like Python.

Also, in my experience programming in Python, I have never needed to do something like this, which is probably because Python wasn't made to do the same things as COBOL was made to do. So, the other reason is that it just wouldn't get used much if there was a built-in.

Answer 3

I (without knowing this for a fact) imagine it would be hard to say (and perhaps what I write here will shine a light on why). So without making reference to any particular language, and trying to cover possible general reasons:

("they" being <X language>'s designers:)

Broad category #1:

They didn't think of it

• They're tackling a problem/application-domain where this was not something that would be critical or obviously valuable
• They like pulling ideas from other languages and being syntax-rich, but just know nothing about COBOL

Broad category #2:

They asked

• What positive value does this provide, and how does it align with or detract from our language's goals?
• How much might this feature be used?
• What would be the maintenance burden to us as the language's designers if we add this?
• What would be the cost to our target audience if we don't add this?
• How could it possibly obscure the meanings of programs?
• How could it potentially have unintended or surprising consequences to some users when it comes to those users adding new data members to either data structure?"

And then after talking about and potentially answering those questions,

• As a whole, they didn't think it was useful enough to justify dedicated syntax
• As a whole, they thought it was not useful
• As a whole, they thought it was the opposite of useful