On 2024-01-24, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> [...]
>> These days, it even supports object oriented code.
>> FWIW, the last ISO COBOL language standard was issued in 2023.
>
> ADD 1 TO COBOL GIVING COBOL

Oh, oh, I have a new one to this oldie:

ADD 100 TO PITCH OF COBOL

(100 cents in a semitone.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 1/24/2024 11:52 AM, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 23/01/2024 21:51, Lawrence D'Oliveiro wrote:
>>> On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:
>>>
>>>> It breaks the rule that, in C, variables and functions are alphnumeric,
>>>> whilst operators are symbols.
>>>
>>> Where is there such a “rule”?
>>>
>> Valid function names have to begin with an alphabetical symbol or
>> (annoyingly for me) an underscore, as do variables. They may not contain
>> non-alphanumerical symbols except for underscore
>
> Dollar symbol ($) is an allowed extension.
>

Big time. For instance Relacy makes use of $:

https://www.1024cores.net/home/relacy-race-detector

;^)

On 24/01/2024 21:15, Lawrence D'Oliveiro wrote:
> On Wed, 24 Jan 2024 18:40:08 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> "Logical disjunction is usually short-circuited ...
>
> I wonder why that shouldn’t apply to anything else. E.g. in
>
> a × (b + c)
>
> if “a” evaluates to zero, why not avoid the computation of “b + c” and
> just return zero as the value of the expression?

Compilers both can and do use such optimisations:

<https://godbolt.org/z/bhPMo8WPW>

int test(int a, int b, int c) {
if (a == 0) {
return a * (b + c);
} else {
return a * (b + c);
}
}

compiles (with gcc -O2) to :

test:
mov eax, edi
test edi, edi
je .L2
add esi, edx
imul eax, esi
..L2:
ret

As long as there are no side-effects evaluating "b" and "c", then if the
compiler knows "a" is 0, it can return 0 without doing the sums.

On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 24.01.2024 17:56, Kaz Kylheku wrote:
>>
>> The Wikipedia page on it is quite good.
>
> The German Wikipedia has a table that is better legible IMO
> https://de.wikipedia.org/wiki/ISO_646

That character 0x24 is funny. Every country listed in that table
just has it as $. But the IRV has to have ¤?

Who the hell needs a symbol indicating unspecified currency?

How about one for unspecified temperature units?

100⁰B ("degrees bullshit")

Is that freezing? Room temperature? Solder-melting? Who knows ...

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 1/24/24 03:10, Janis Papanagnou wrote:
>> On 23.01.2024 23:37, Kalevi Kolttonen wrote:
>>>
>>> [...] I am
>>> pretty sure that not all computer languages
>>> provide guarantees about the order of evaluation.
>>
>> What?!
>
> Could you explain what surprises you about that statement? As quoted,
> it's a general statement which includes C: "Except as specified later,
> side effects and value computations of subexpressions are unsequenced."

Pretty much any language has to guarantee *something* about
order of evaluation, somewhere.

Like for instance that calculating output is not possible before a
needed input is available.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-01-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 24 Jan 2024 07:58:44 -0800, Keith Thompson wrote:
>
>> Trigraphs, digraphs, and <iso646.h> were all introduced to support
>> systems that *don't* support the full ASCII character set.
>
> Where is there a national character set that doesn’t support the symbols
> for which iso646.h introduces synonyms?

See table in German Wikipedia page found by Janis

https://de.wikipedia.org/wiki/ISO_646#Aufbau

Let me reproduce that here:

ISO 646-IRV # ¤ @ [ \ ] ^ ` { | } ~
Deutschland # $ § Ä Ö Ü ^ ` ä ö ü ß
Schweiz ù $ à é ç ê î ô ä ö ü û
USA (ASCII) # $ @ [ \ ] ^ ` { | } ~
Großbritannien £ $ @ [ \ ] ^ ` { | } ~
Frankreich £ $ à ° ç § ^ ` é ù è ¨
Kanada # $ à â ç ê î ô é ù è û
Finnland # $ @ Ä Ö Å Ü é ä ö å ü
Norwegen # $ @ Æ Ø Å ^ ` æ ø å ~
Schweden # $ É Ä Ö Å Ü é ä ö å ü
Italien £ $ § ° ç é ^ ù à ò ù ì
Niederlande £ $ ¾ ÿ ½ | ^ ` ¨ ƒ ¼ ´
Spanien £ $ § ¡ Ñ ¿ ^ ` ° ñ ç ~
Portugal # $ @ Ã Ç Õ ^ ` ã ç õ ~

These are 7 bit codes, that are essentially variations on ASCII,
distinct from ISO-8859 (a.k.a. "ISO Latin").

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 24 Jan 2024 14:17:04 -0000 (UTC), Lew Pitcher wrote:
>
>> and, yes, COBOL programmers are still in demand, mostly by financial
>> institutions that have hundreds of millions of lines of COBOL code to
>> maintain.
>
>I suspect a lot of those institutions have already gone out of business,
>or are close to going out of business. And the amounts they have to pay
>COBOL programmers to maintain their code are hastening that end.
>
>> Are you certain that you want your taxes to be calculated in
>> floatingpoint? ;-)
>
>How else would you handle compound interest?

Fixed point arithmetic, of course. E.g. for
currency, work with 'mils' and round (using
bankers rounding) the result to the desired
precision (e.g. cents).

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-01-24, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> [...]
>>> These days, it even supports object oriented code.
>>> FWIW, the last ISO COBOL language standard was issued in 2023.
>>
>> ADD 1 TO COBOL GIVING COBOL
>
>Oh, oh, I have a new one to this oldie:
>
>ADD 100 TO PITCH OF COBOL
>
>(100 cents in a semitone.)

?LI SYSTEM/OPERATOR
?COMPILE STREK COBOL LIB MEM + 300.
?DATA CARD
$SET CODE
IDENTIFICATION DIVISION.
PROGRAM-ID. STREK.
AUTHOR. KURT WILHELM.
INSTALLATION. OAKLAND UNIVERSITY.
DATE-WRITTEN. COMPLETED SEPTEMBER 1, 1979.
*
*******************************************************
* STAR_TREK SIMULATES AN OUTER SPACE ADVENTURE GAME *
* ON A REMOTE TERMINAL. THE USER COMMANDS THE U.S.S. *
* ENTERPRISE, AND THRU VARIOUS OFFENSIVE AND DEFEN- *
* SIVE COMMANDS, TRAVELS THROUGHOUT THE GALAXY ON A *
* MISSION TO DESTROY ALL KLINGONS, WHICH ALSO MANEU- *
* VER AND FIRE ON THE ENTERPRISE. *
*******************************************************
*

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. V-380.
OBJECT-COMPUTER. V-300.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 EOF-FLAG PIC X VALUE "N".
01 STAR-TABLE.
05 ROW OCCURS 42 TIMES.
10 KOLUMN PIC X OCCURS 42 TIMES.
01 RCTR PIC 99.
01 KCTR PIC 99.
01 COMMANDS-X.
05 COMMAND PIC X(3).
88 NAVIGATE VALUE "NAV".
88 PHASERS VALUE "PHA".
88 TORPEDO VALUE "TOR".
88 SHIELDS VALUE "DEF".
88 DOCK VALUE "DOC".
88 LIB-COM VALUE "COM".
88 NAV-C VALUE "NAV".
88 PHA-C VALUE "PHA".
88 TOR-C VALUE "TOR".
88 DEF-C VALUE "DEF".
88 DOC-C VALUE "DOC".
88 COM-C VALUE "COM".
05 ENTRY1 PIC 9.
05 ENTRY2 PIC 9.
01 MINI-TABLE.
05 MROW OCCURS 14 TIMES.
10 MCOL PIC X OCCURS 14 TIMES.
01 RCNTR PIC 99.
01 KCNTR PIC 99.
01 X PIC 999.
01 Y PIC 999.
01 WS-DATE PIC 9(4) COMP.
01 TIME-FLAG PIC 9.
88 TIME-FLAG-SET VALUE 1.
01 MAX-NO PIC 999.
01 HQ1 PIC 9.
01 HQ2 PIC 9.
01 T-STORE PIC 9(4) COMP.
01 ATTACK-FLAG PIC 9.
88 KLINGONS-ATTACKING VALUE 1.
....
MOVE 0 TO TOO-LATE-FLAG.
DISPLAY " ".
DISPLAY " *STAR TREK* ".
DISPLAY " ".
DISPLAY "CONGRATULATIONS - YOU HAVE JUST BEEN APPOINTED ".
DISPLAY "CAPTAIN OF THE U.S.S. ENTERPRISE. ".
DISPLAY " ".
DISPLAY "PLEASE ENTER YOUR NAME, CAPTAIN ".
ACCEPT NAME-X.
DISPLAY "AND YOUR SKILL LEVEL (1-4)? ".
ACCEPT SKILL-LEV.
IF SKILL-LEV NOT NUMERIC OR SKILL-LEV < 1 OR SKILL-LEV > 4
DISPLAY "INVALID SKILL LEVEL "
DISPLAY "ENTER YOUR SKILL LEVEL (1-4) "
ACCEPT SKILL-LEV
IF SKILL-LEV NOT NUMERIC OR SKILL-LEV < 1 OR SKILL-LEV >
- 4
MOVE 1 TO SKILL-LEV
DISPLAY "YOUR SKILL LEVEL MUST BE 1 ".
MOVE 0 TO VAB5.
MOVE 0 TO VAB6.
INSPECT NAME-X TALLYING VAB6 FOR ALL "A".
INSPECT NAME-X TALLYING VAB6 FOR ALL "E".
ADD 1 TO VAB6.
INSPECT NAME-X TALLYING VAB5 FOR ALL " ".
COMPUTE VAB6 ROUNDED = (VAB5 / 1.75) + (VAB6 / SKILL-LEV).
COMPUTE K-OR ROUNDED = (SKILL-LEV * 4) + VAB6 + 5.
COMPUTE VAB1 = 9 - SKILL-LEV.
COMPUTE VAB2 ROUNDED = (SKILL-LEV / 3) * K-OR.
MOVE K-OR TO KLINGONS.
MOVE VAB1 TO VAE1.
ACCEPT WS-TIME FROM TIME.
MOVE WS-MIN OF WS-TIME TO DS-MIN.
MOVE WS-SEC OF WS-TIME TO DS-SEC.
MOVE DS-TABLE TO S-DATE.
ADD 16 TO DS-MIN.
IF DS-MIN > 59
MOVE 1 TO TIME-FLAG
ELSE
MOVE 0 TO TIME-FLAG.
MOVE DS-TABLE TO DS-DATE.
....

On 2024-01-24, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> Are you certain that you want your taxes to be calculated in
> floatingpoint? ;-)

I've never calculated my taxes in anything but floating-point.

The Canada Revenue Agency will not refund or charge amounts less than a
couple of dollars so even if floating-point introduced errors (which it
doesn't) it wouldn't matter.

Ordinary personal accounting, and small business accounting, can be
done entirely in IEEE 754 double, if used correctly. Or else using
integers for the ledger values, and taking at trip to floating point
for percentage calculations and such, which get rounded back to the
rational representation.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 1/24/2024 3:20 PM, Kaz Kylheku wrote:
> On 2024-01-24, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> Are you certain that you want your taxes to be calculated in
>> floatingpoint? ;-)
>
> I've never calculated my taxes in anything but floating-point.

At what precision? ;^)

>
> The Canada Revenue Agency will not refund or charge amounts less than a
> couple of dollars so even if floating-point introduced errors (which it
> doesn't) it wouldn't matter.
>
> Ordinary personal accounting, and small business accounting, can be
> done entirely in IEEE 754 double, if used correctly. Or else using
> integers for the ledger values, and taking at trip to floating point
> for percentage calculations and such, which get rounded back to the
> rational representation.
>

On Wed, 24 Jan 2024 20:25:00 -0000 (UTC), Lew Pitcher wrote:

> On Wed, 24 Jan 2024 20:11:33 +0000, Lawrence D'Oliveiro wrote:
>
>> Where is there a national character set that doesn’t support the
>> symbols for which iso646.h introduces synonyms?
>
> EBCDIC-US, for one. It lacks the CIRCUMFLEX (^) character.

Were any of the EBCDICs official standards anywhere in the world, outside
of IBM?

Thinking about what the “A” in “ASCII” stands for ...

On Wed, 24 Jan 2024 19:33:09 +0000, Malcolm McLean wrote:

> I've discussed this ad infinitum with people who don't really understand
> what the term "function" means. Anththing that maps one set to another
> set such that there is one and only one mapping from each member if the
> struture set to the result set is mathematically a "function".
>
> Sizeof clearly counts.

It does in the mathematical sense. But in the C sense, a “function” is a
block of code which is called at runtime with zero or more arguments and
returns a result (which might be void). It can also have side-effects on
the machine state.

It helps the discussion to be clear what your terms mean. Otherwise the
people you are arguing with have a right to be indignant at what they
might perceive to be wilful obtuseness.

On Wed, 24 Jan 2024 19:52:58 GMT, Scott Lurndal wrote:

> Dollar symbol ($) is an allowed extension.

I wonder if we have DEC to thank for that ... ?

On Wed, 24 Jan 2024 22:13:06 GMT, Scott Lurndal wrote:

> 01 STAR-TABLE.
> 05 ROW OCCURS 42 TIMES.
> 10 KOLUMN PIC X OCCURS 42 TIMES.
> ...
> 01 MINI-TABLE.
> 05 MROW OCCURS 14 TIMES.
> 10 MCOL PIC X OCCURS 14 TIMES.

*Sigh* Imagine a language without named constants.

> DISPLAY " ".
> DISPLAY " *STAR TREK* ".
> DISPLAY " ".
> DISPLAY "CONGRATULATIONS - YOU HAVE JUST BEEN APPOINTED ".
> DISPLAY "CAPTAIN OF THE U.S.S. ENTERPRISE. ".
> DISPLAY " ".
> DISPLAY "PLEASE ENTER YOUR NAME, CAPTAIN ".
> ACCEPT NAME-X.

And with crummy string handling and I/O.

On Thu, 25 Jan 2024 00:17:01 +0000, Lawrence D'Oliveiro wrote:

> On Wed, 24 Jan 2024 20:25:00 -0000 (UTC), Lew Pitcher wrote:
>
>> On Wed, 24 Jan 2024 20:11:33 +0000, Lawrence D'Oliveiro wrote:
>>
>>> Where is there a national character set that doesn’t support the
>>> symbols for which iso646.h introduces synonyms?
>>
>> EBCDIC-US, for one. It lacks the CIRCUMFLEX (^) character.
>
> Were any of the EBCDICs official standards anywhere in the world, outside
> of IBM?

Who cares? The better questions would be:
- Are there C compilers for IBM mainframe systems that use EBCDIC?
Yes, indeed there are.
- Is IBM represented on the ISO C Standards committee?
Yes, it is.

> Thinking about what the “A” in “ASCII” stands for ...

Thinking of what the "E" in "ECMA-6" stands for
(https://ecma-international.org/publications-and-standards/standards/ecma-6/)
:-)

--
Lew Pitcher
"In Skills We Trust"

On 24/01/2024 16:27, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> (It could not have been added as "**", because - as Keith said in
>> another post - "x ** y" already has a meaning in C. While I believe
>> it would be possible to distinguish the uses based on the type of "y",
>> other than for the literal 0, having "x ** y" mean two /completely/
>> different things depending on the type of "y" would not be a good idea
>> for C.)
>
> The problem with a "**" exponentation operator is lexical. It's common
> to have two consecutive unary "*" operators in declarations and
> expression:
> char **argv;
> char c = **argv;
> Adding a "**" operator would have made the above invalid due to the
> "maximal munch" rule, before the type of the argument is even
> considered.
>
> See also x+++++y, which might be intended as x++ + ++y, but is scanned
> as x ++ ++ + y, a syntax error.
>
> C could have added "**" very early, but then we'd have to write
> "* *argv" or "*(*argv)".

Given the other syntax decisions, probably the best bet would have been
to have a named /operator/ called 'pow'. With two operatands, using
function-like syntax 'pow(x, y)' would look better than 'x pow y'.

This could then be defined over float, double, int and friends.

You wouldn't be able to have a reference to it as you can with a
function, but why is that so important? You can't have reference to the
multiply operator either!

On Wed, 24 Jan 2024 20:31:05 -0000 (UTC), Lew Pitcher wrote:

> On Wed, 24 Jan 2024 20:21:37 +0000, Lawrence D'Oliveiro wrote:
>
>> I suspect a lot of those institutions have already gone out of
>> business, or are close to going out of business.
>
> And who do /you/ bank with?

Are you talking about the bank I originally signed up with, or the one
that acquired it?

Even if both of them were making heavy use of COBOL, what was formerly two
separate COBOL installations is now just one COBOL installation.

So whichever way you look at it, COBOL usage is inevitably shrinking.

On 1/24/2024 4:52 PM, bart wrote:
> On 24/01/2024 16:27, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> (It could not have been added as "**", because - as Keith said in
>>> another post - "x ** y" already has a meaning in C.  While I believe
>>> it would be possible to distinguish the uses based on the type of "y",
>>> other than for the literal 0, having "x ** y" mean two /completely/
>>> different things depending on the type of "y" would not be a good idea
>>> for C.)
>>
>> The problem with a "**" exponentation operator is lexical.  It's common
>> to have two consecutive unary "*" operators in declarations and
>> expression:
>>      char **argv;
>>      char c = **argv;
>> Adding a "**" operator would have made the above invalid due to the
>> "maximal munch" rule, before the type of the argument is even
>> considered.
>>
>> See also x+++++y, which might be intended as x++ + ++y, but is scanned
>> as x ++ ++ + y, a syntax error.
>>
>> C could have added "**" very early, but then we'd have to write
>> "* *argv" or "*(*argv)".
>
> Given the other syntax decisions, probably the best bet would have been
> to have a named /operator/ called 'pow'. With two operatands, using
> function-like syntax 'pow(x, y)' would look better than 'x pow y'.
>
> This could then be defined over float, double, int and friends.
>
> You wouldn't be able to have a reference to it as you can with a
> function, but why is that so important? You can't have reference to the
> multiply operator either!
>
>

Would p * p * p * p be pow(p, 4)? ;^)

On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 24 Jan 2024 20:25:00 -0000 (UTC), Lew Pitcher wrote:
>
>> On Wed, 24 Jan 2024 20:11:33 +0000, Lawrence D'Oliveiro wrote:
>>
>>> Where is there a national character set that doesn’t support the
>>> symbols for which iso646.h introduces synonyms?
>>
>> EBCDIC-US, for one. It lacks the CIRCUMFLEX (^) character.
>
> Were any of the EBCDICs official standards anywhere in the world, outside
> of IBM?

Let's make a song!

(To the tune of Mozart, K265).

A, B, C, D, E-F-G-H, I

dead-space plus/minus, J, K, L-M-N-O-Pie

R, dead-space, tilde, S, T-U-V

A-I-X-Sux, Y use System Z?

I almost know by ebsy-dickee-dee.

Sing "To hell with IBM!" with me.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> Even if both of them were making heavy use of COBOL, what was formerly two
> separate COBOL installations is now just one COBOL installation.
>
> So whichever way you look at it, COBOL usage is inevitably shrinking.

Only if the two merged COBOLS aren't larger than the original two
combined.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 24 Jan 2024 19:52:58 GMT, Scott Lurndal wrote:
>
>> Dollar symbol ($) is an allowed extension.
>
> I wonder if we have DEC to thank for that ... ?

Perhaps. You have to follow the money to find out where that came from.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 24 Jan 2024 20:25:00 -0000 (UTC), Lew Pitcher wrote:
>
>> On Wed, 24 Jan 2024 20:11:33 +0000, Lawrence D'Oliveiro wrote:
>>
>>> Where is there a national character set that doesn’t support the
>>> symbols for which iso646.h introduces synonyms?
>>
>> EBCDIC-US, for one. It lacks the CIRCUMFLEX (^) character.
>
>Were any of the EBCDICs official standards anywhere in the world, outside
>of IBM?

Defacto within the particular manufacturer, yes.

>
>Thinking about what the “A” in “ASCII” stands for ...

Hard to tell with all the unreadable UTF-8 :-)

I believe it was the caret that printed as the EBCDIC 'not' �
character when printed on an EBCDIC printer.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 24 Jan 2024 22:13:06 GMT, Scott Lurndal wrote:
>
>> 01 STAR-TABLE.
>> 05 ROW OCCURS 42 TIMES.
>> 10 KOLUMN PIC X OCCURS 42 TIMES.
>> ...
>> 01 MINI-TABLE.
>> 05 MROW OCCURS 14 TIMES.
>> 10 MCOL PIC X OCCURS 14 TIMES.
>
>*Sigh* Imagine a language without named constants.

I'm not sure of your point - you left out:

01 COMMANDS-X.
05 COMMAND PIC X(3).
88 NAVIGATE VALUE "NAV".
88 PHASERS VALUE "PHA".
88 TORPEDO VALUE "TOR".
88 SHIELDS VALUE "DEF".
88 DOCK VALUE "DOC".
88 LIB-COM VALUE "COM".
88 NAV-C VALUE "NAV".
88 PHA-C VALUE "PHA".
88 TOR-C VALUE "TOR".
88 DEF-C VALUE "DEF".
88 DOC-C VALUE "DOC".
88 COM-C VALUE "COM".

If those aren't named constants, what do you call them?

>
>> DISPLAY " ".
>> DISPLAY " *STAR TREK* ".
>> DISPLAY " ".
>> DISPLAY "CONGRATULATIONS - YOU HAVE JUST BEEN APPOINTED ".
>> DISPLAY "CAPTAIN OF THE U.S.S. ENTERPRISE. ".
>> DISPLAY " ".
>> DISPLAY "PLEASE ENTER YOUR NAME, CAPTAIN ".
>> ACCEPT NAME-X.
>
>And with crummy string handling and I/O.

Ah, I detect sarcasm.

In article <cXisN.134975$taff.87042@fx41.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Wed, 24 Jan 2024 22:13:06 GMT, Scott Lurndal wrote:
>>
>>> 01 STAR-TABLE.
>>> 05 ROW OCCURS 42 TIMES.
>>> 10 KOLUMN PIC X OCCURS 42 TIMES.
>>> ...
>>> 01 MINI-TABLE.
>>> 05 MROW OCCURS 14 TIMES.
>>> 10 MCOL PIC X OCCURS 14 TIMES.
>>
>>*Sigh* Imagine a language without named constants.
>
>I'm not sure of your point - you left out:
>
> 01 COMMANDS-X.
> 05 COMMAND PIC X(3).
> 88 NAVIGATE VALUE "NAV".
> 88 PHASERS VALUE "PHA".
> 88 TORPEDO VALUE "TOR".
> 88 SHIELDS VALUE "DEF".
> 88 DOCK VALUE "DOC".
> 88 LIB-COM VALUE "COM".
> 88 NAV-C VALUE "NAV".
> 88 PHA-C VALUE "PHA".
> 88 TOR-C VALUE "TOR".
> 88 DEF-C VALUE "DEF".
> 88 DOC-C VALUE "DOC".
> 88 COM-C VALUE "COM".
>
>If those aren't named constants, what do you call them?
>
>>
>>> DISPLAY " ".
>>> DISPLAY " *STAR TREK* ".
>>> DISPLAY " ".
>>> DISPLAY "CONGRATULATIONS - YOU HAVE JUST BEEN APPOINTED ".
>>> DISPLAY "CAPTAIN OF THE U.S.S. ENTERPRISE. ".
>>> DISPLAY " ".
>>> DISPLAY "PLEASE ENTER YOUR NAME, CAPTAIN ".
>>> ACCEPT NAME-X.
>>
>>And with crummy string handling and I/O.
>
>Ah, I detect sarcasm.

I think you detect crankery. Please don't feed the troll.

- Dan C.

On 1/24/2024 5:24 PM, Kaz Kylheku wrote:
> On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> Even if both of them were making heavy use of COBOL, what was formerly two
>> separate COBOL installations is now just one COBOL installation.
>>
>> So whichever way you look at it, COBOL usage is inevitably shrinking.
>
> Only if the two merged COBOLS aren't larger than the original two
> combined.
>

LOL!