<p>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 <code>CORRESPONDING</code> keyword.</p>
<p>It could be used in three ways:</p>
<pre><code>MOVE CORRESPONDING INPUT_RECORD TO OUTPUT_RECORD
ADD CORRESPONDING INPUT_RECORD TO OUTPUT_RECORD
SUBTRACT CORRESPONDING INPUT_RECORD FROM OUTPUT_RECORD
</code></pre>
<p>The RECORDs can be considered the equivalent of a C structure or a JavaScript object:</p>
<pre><code>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.
</code></pre>
<p>With a single statement, all the fields that have the same name in <code>INPUT_RECORD</code> and <code>OUTPUT_RECORD</code> are processed (only numeric fields are considered for <code>ADD</code> and <code>SUBTRACT</code>).</p>
<p>In this case, only <code>VALUE</code> and <code>COUNT</code> are processed.</p>
<p>The data is also converted as necessary (e.g. <code>VALUE</code> could be floating point in one record and packed-decimal in the other, or strings could be different lengths and require padding).</p>
<p>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.</p>
<p>The amount of coding and debugging time saved was incredible.</p>
<p>Why did other high-level languages written since COBOL decide not to include a similar operation?</p>

<language-design><high-level-languages>
Why did other high-level languages not implement COBOL's `CORRESPONDING` keyword?
CC BY-SA 4.0
2023-05-21T14:08:55.123Z
This seems to basically be the same as the `...` operator in javascript or the `**` operator in python right?
mousetail 'he-him'
CC BY-SA 4.0
2023-05-21T14:42:37.210Z
@mousetail, no.  The records can have other fields and be in different orders. Only the fields with identical names are processed.  I've added a (not-so-great) example.
Ray Butterworth
CC BY-SA 4.0
2023-05-21T14:55:18.483Z
`...` and `**` don't preserve order, but you are right they don't generally convert data types
mousetail 'he-him'
CC BY-SA 4.0
2023-11-15T22:51:26.723Z
I've never used COBOL, but what you describe sounds similar to PL/I's assignment "by name".
supercat
<h3>Because it's simple to do yourself and there's not much use for it</h3>
<p>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:</p>
<pre class="lang-python prettyprint-override"><code>[(v, y.__dict__[k]) for k, v in x.__dict__.items() if k in y.__dict__]
</code></pre>
<p>(<a href="https://ato.pxeger.com/run?1=hYxLCsIwFEXnWcUdJvIs-EUEp65B0RJq22Dox2Ki2LU4sBPdgKvpbkxJ0aGj8-673HN_VbU9nsqmfcR5ZAw2SwYkqYKUutRWSm7SXInuC3RnEJHnoWeMFUaEMWHCmJds_0q-456Jk0wJM8KcsRuhdnnDBWHLBctd2D8vVg0X7XrHr64OpEx07My7LBRQpzMywhW6xO1bBdqmheECWiHrqt8q9LZ3ddal5YMiqri5FIRcCN80jecH" rel="nofollow noreferrer">Attempt This Online!</a>)</p>
<p>Because of this, it doesn't really make sense to make a built-in for it in languages like Python.</p>
<p>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.</p>

CC BY-SA 4.0
2023-05-21T16:07:06.647Z
2023-05-21T16:07:06.647Z
The Thonnu
CC BY-SA 4.0
2023-05-21T16:30:11.027Z
Yes, though there'd also have to be an f-string to convert the format, and some kind of test for numeric types for the ADD and SUBTRACT. ¶ "*Python wasn't made to do the same things as COBOL*" — Right.  One of my real-world jobs was to process accounting records in C. That involved reading records from differently formatted files and merging them into a common record format. It took a lot of code, and nearly all of it was spent parsing the input records. In a COBOL environment the input records never needed to be parsed. (When COBOL was designed, parsing would have been very expensive.)
Ray Butterworth
CC BY-SA 4.0
2023-05-21T18:03:04.720Z
"It's so simple!" *uses what in some other languages requires metaprogramming- and not all of those languages have that kind of metaprogramming. Unless you're interpreting the question as only being about runtime dictionary structures? ... Is it? Has it really ruled out C/C++ structs? I mean- I'm not against a point that says "it's so simple" *does it without the field/member iteration.
starball
<p>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:</p>
<p>(&quot;they&quot; being &lt;X language&gt;'s designers:)</p>
<p>Broad category #1:</p>
<p>They didn't think of it</p>
<ul>
<li>They're tackling a problem/application-domain where this was not something that would be critical or obviously valuable</li>
<li>They like pulling ideas from other languages and being syntax-rich, but just know nothing about COBOL</li>
</ul>
<p>Broad category #2:</p>
<p>They asked</p>
<ul>
<li>What positive value does this provide, and how does it align with or detract from our language's goals?</li>
<li>How much might this feature be used?</li>
<li>What would be the maintenance burden to us as the language's designers if we add this?</li>
<li>What would be the cost to our target audience if we <em>don't</em> add this?</li>
<li>How could it possibly obscure the meanings of programs?</li>
<li>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?&quot;</li>
</ul>
<p>And then after talking about and potentially answering those questions,</p>
<ul>
<li>As a whole, they didn't think it was useful enough to justify dedicated syntax</li>
<li>As a whole, they thought it was not useful</li>
<li>As a whole, they thought it was the opposite of useful</li>
</ul>

CC BY-SA 4.0
2023-05-21T18:16:10.387Z
2023-05-21T19:00:46.107Z
2023-05-21T19:00:46.107Z
starball
<h2>Because of <em>Types</em> and <em>Composition</em></h2>
<p>I would say the reasons include because we have types and composition.</p>
<p>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 &quot;corresponding&quot; does only part of the job.</p>
<pre><code>struct X
{
   alpha: int
   beta: int
   gamma: int
}

struct Y
{
   beta: int
   gamma: int
   delta: int
}
</code></pre>
<p>So you can copy beta and gamma because they correspond. Great! but what about alpha and delta?</p>
<p>COBOL doesn't have proper types it has <a href="https://www.tutorialspoint.com/cobol/cobol_data_layout.htm" rel="nofollow noreferrer">copybooks</a>
Though there are OO variants now that do.</p>
<p>So to copy a structure you had to do something like your move corresponding.
Many languages will auto generate copy constructors for <a href="https://stackoverflow.com/questions/146452/what-are-pod-types-in-c">plain old data types</a>.</p>
<p>So the syntax given:</p>
<pre><code> var foo: X;
 var bar: X;
</code></pre>
<p>is just:</p>
<pre><code> foo = bar;
</code></pre>
<p>Much more concise and with tighter semantics than &quot;move corresponding&quot;.</p>
<p>Finally we have composition. If the corresponding fields are important why not extract them into a dedicated type:</p>
<pre><code>struct Common
{
   beta: int
   gamma: int
}

struct X
{
   alpha: int
   common: Common
}

struct Y
{
   common: Common
   delta: int
}
</code></pre>
<p>Now you can write:</p>
<pre><code>foo.common = bar.common
</code></pre>
<p>Inheritance works similarly.</p>

CC BY-SA 4.0
2023-06-02T00:45:37.890Z
2023-06-03T11:31:47.833Z
2023-06-03T11:31:47.833Z
Bruce Adams
# Why did other high-level languages not implement COBOL's `CORRESPONDING` keyword?
Posted by: username_0 on 2023-05-21
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?
**Tags:** language-design high-level-languages
> **Comments:**
> **username_1**: This seems to basically be the same as the `...` operator in javascript or the `**` operator in python right?  
> **username_0**: @mousetail, no.  The records can have other fields and be in different orders. Only the fields with identical names are processed.  I've added a (not-so-great) example.  
> **username_1**: `...` and `**` don't preserve order, but you are right they don't generally convert data types  
> **username_2**: I've never used COBOL, but what you describe sounds similar to PL/I's assignment "by name".  
---
## 3 answers
### Answer by username_5 on 2023-06-02. Score: 5
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 by username_3 on 2023-05-21. Score: 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.
> **Comments:**
> **username_0** (2023-05-21): Yes, though there'd also have to be an f-string to convert the format, and some kind of test for numeric types for the ADD and SUBTRACT. ¶ "*Python wasn't made to do the same things as COBOL*" — Right.  One of my real-world jobs was to process accounting records in C. That involved reading records from differently formatted files and merging them into a common record format. It took a lot of code, and nearly all of it was spent parsing the input records. In a COBOL environment the input records never needed to be parsed. (When COBOL was designed, parsing would have been very expensive.)  
> **username_4** (2023-05-21): "It's so simple!" *uses what in some other languages requires metaprogramming- and not all of those languages have that kind of metaprogramming. Unless you're interpreting the question as only being about runtime dictionary structures? ... Is it? Has it really ruled out C/C++ structs? I mean- I'm not against a point that says "it's so simple" *does it without the field/member iteration.  
---
### Answer by username_4 on 2023-05-21. Score: 2
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 '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
---
