One feature that I find makes them easier to use, and harder to
implement, is no reserved words.
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]
From: "gah4" <gah4@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of
ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and
years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]
On Thursday, December 1, 2022 at 4:18:24 PM UTC-8, gah4 wrote:
(snip)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.(snip)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]COBOL had many useful English words used.
As well as I know it, the idea for PL/I was that you shouldn't need to know about the parts of the language that you weren't using, even know the words.
But also, PL/I more than other languages has simple rules, instead
of arbitrary restrictions. You can use any expression in any place where
an expression is allowed.
Fortran has always, and still does, have unobvious restrictions on how expressions can be used. Some it seems intentionally to make it harder
for the programmer. That is, to discourage practices that some don't like.
My favorite complaint is about using REAL variables in DO loops.
Yes there are good reasons not to do it, but it isn't up to the language
to decide that.
The actual reason I follow this one, is that many (many!) years ago
I would sometimes translate BASIC programs to Fortran, where all
variables are Fortran REAL.
PL/I allowed array expressions from the beginning, Fortran added
them much later. PL/I has a simple rule. The subscripts have the
same value for all arrays in the expression.
Fortran has complicated rules, where some arrays index from one,
even if they are declared with different lower bound. You have to
be extremely careful, which one it is using. And it gets even worse
when you pass arrays to subroutines.
From: "gah4" <gah4@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of
ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and
years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]
On Thursday, December 1, 2022 at 4:18:24 PM UTC-8, gah4 wrote:
(snip)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
(snip)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]
COBOL had many useful English words used.
As well as I know it, the idea for PL/I was that you shouldn't need to know about the parts of the language that you weren't using, even know the words.
But also, PL/I more than other languages has simple rules, instead
of arbitrary restrictions. You can use any expression in any place where
an expression is allowed.
On 12/3/22 5:53 AM, Robin Vowels wrote:
From: "gah4" <gah4@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of
ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to
implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and
years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]
Yes, but you’re not required to writing such ridiculous code, and adding only a few reserved words makes the language harder to learn, because it forces to you memorize more exceptions.
On the other hand, running with zero reserved words, as with PL/I and FORTRAN, or even with a merely minimal set, as in C, requires extra
keywords and punctuation (usually parentheses).
PL/I if x = 0 then
x = 1;
else do:
x = x + 2;
e = e + 1;
end;
C if (x == 0)
x = 1;
else {
x += 2;
e += 1;
}
Swift if x == 0 {
x = 1
} else {
x += 2
e += 1
}
Honestly, in this, as in most matters, I like Swift best.
But Swift has one really neat trick when it comes to reserved words.
var `in` = 0
var out = 0
The backtick quotes make a reserved word safe for use as a name.
(Swift
has features comparable to PL/I GET and PUT DATA, so just changing the
name may not be feasible.)
On 12/3/22 5:53 AM, Robin Vowels wrote:
From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
.It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of
ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]Yes, but you’re not required to writing such ridiculous code, and adding only a few reserved words makes the language harder to learn, because it forces to you memorize more exceptions.
On the other hand, running with zero reserved words, as with PL/I and FORTRAN, or even with a merely minimal set, as in C, requires extra
keywords and punctuation (usually parentheses).
PL/I if x = 0 then
x = 1;
else do:
x = x + 2;
e = e + 1;
end;
C if (x == 0).
x = 1;
else {
x += 2;
e += 1;
}
Swift if x == 0 {
x = 1
} else {
x += 2
e += 1
}.
Honestly, in this, as in most matters, I like Swift best.
But Swift has one really neat trick when it comes to reserved words.
var `in` = 0
var out = 0
The backtick quotes make a reserved word safe for use as a name. (Swift
has features comparable to PL/I GET and PUT DATA, so just changing the
name may not be feasible.)
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote:
On 12/3/22 5:53 AM, Robin Vowels wrote:.
From: "gah4" <ga...@u.washington.edu>Yes, but you’re not required to writing such ridiculous code, and adding >> only a few reserved words makes the language harder to learn, because it
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of
ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and
years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John]
forces to you memorize more exceptions.
On the other hand, running with zero reserved words, as with PL/I and
FORTRAN, or even with a merely minimal set, as in C, requires extra
keywords and punctuation (usually parentheses).
PL/I if x = 0 then
x = 1;
else do:
x = x + 2;
e = e + 1;
end;
In PL/I :
IF X = 0 THEN
DO; X = 1; END;
ELSE
DO;
X = X + 2; E = E + 1;
END;
and similarly in Fortran.
The bracketing is performed by keywords that are more easily seen than
the single character of curly braces.
.
C if (x == 0).
x = 1;
else {
x += 2;
e += 1;
}
Swift if x == 0 {
x = 1
} else {
x += 2
e += 1
These assignments can be written the same way in PL/I ,
but I prefer the traditional method.
.
}.
Honestly, in this, as in most matters, I like Swift best.
But Swift has one really neat trick when it comes to reserved words.
var `in` = 0
var out = 0
The backtick quotes make a reserved word safe for use as a name. (Swift
has features comparable to PL/I GET and PUT DATA, so just changing the
name may not be feasible.)
In PL/I and Fortran, reserved words are safe for a name.
Swift seems to be clumsy: you still need to keep in mind which words are keywords?
Languages should make it easy for the programmer, not easy for the compiler writer.
On 12/5/22 3:30 PM, Robin Vowels wrote:
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote:
On 12/3/22 5:53 AM, Robin Vowels wrote:.
From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of
ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to
implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and
years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John] >>> Yes, but you’re not required to writing such ridiculous code, and adding >>> only a few reserved words makes the language harder to learn, because it >>> forces to you memorize more exceptions.
On the other hand, running with zero reserved words, as with PL/I and
FORTRAN, or even with a merely minimal set, as in C, requires extra
keywords and punctuation (usually parentheses).
PL/I if x = 0 then
x = 1;
else do:
x = x + 2;
e = e + 1;
end;
In PL/I :
IF X = 0 THEN
DO; X = 1; END;
ELSE
DO;
X = X + 2; E = E + 1;
END;
and similarly in Fortran.
The bracketing is performed by keywords that are more easily seen than
the single character of curly braces.
.
C if (x == 0).
x = 1;
else {
x += 2;
e += 1;
}
Swift if x == 0 {
x = 1
} else {
x += 2
e += 1
These assignments can be written the same way in PL/I ,
but I prefer the traditional method.
.
}.
Honestly, in this, as in most matters, I like Swift best.
But Swift has one really neat trick when it comes to reserved words.
var `in` = 0
var out = 0
The backtick quotes make a reserved word safe for use as a name. (Swift
has features comparable to PL/I GET and PUT DATA, so just changing the
name may not be feasible.)
In PL/I and Fortran, reserved words are safe for a name.
No, PL/I and FORTRAN don’t /have/ reserved words.
Swift seems to be clumsy: you still need to keep in mind which words are keywords?
Languages should make it easy for the programmer, not easy for the compiler writer.
But the FORTRAN-PL/I model requires a good deal of extra punctuation. It
also requires the CALL keyword, which, especially in subsystem
environments like CICS or any sort of GUI, can nearly make anyone trying
to read the code go blind.
John W Kennedy <john.w.kennedy@gmail.com> wrote:
On 12/5/22 3:30 PM, Robin Vowels wrote:
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote: >>>> On 12/3/22 5:53 AM, Robin Vowels wrote:
.From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of >>>>> ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to
implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and >>>>> years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John] >>>> Yes, but you’re not required to writing such ridiculous code, and adding >>>> only a few reserved words makes the language harder to learn, because it >>>> forces to you memorize more exceptions.
On the other hand, running with zero reserved words, as with PL/I and
FORTRAN, or even with a merely minimal set, as in C, requires extra
keywords and punctuation (usually parentheses).
PL/I if x = 0 then
x = 1;
else do:
x = x + 2;
e = e + 1;
end;
In PL/I :
IF X = 0 THEN
DO; X = 1; END;
ELSE
DO;
X = X + 2; E = E + 1;
END;
and similarly in Fortran.
The bracketing is performed by keywords that are more easily seen than
the single character of curly braces.
.
C if (x == 0).
x = 1;
else {
x += 2;
e += 1;
}
Swift if x == 0 {
x = 1
} else {
x += 2
e += 1
These assignments can be written the same way in PL/I ,
but I prefer the traditional method.
.
}.
Honestly, in this, as in most matters, I like Swift best.
But Swift has one really neat trick when it comes to reserved words.
var `in` = 0
var out = 0
The backtick quotes make a reserved word safe for use as a name. (Swift >>>> has features comparable to PL/I GET and PUT DATA, so just changing the >>>> name may not be feasible.)
In PL/I and Fortran, reserved words are safe for a name.
No, PL/I and FORTRAN don’t /have/ reserved words.
Swift seems to be clumsy: you still need to keep in mind which words are keywords?
Languages should make it easy for the programmer, not easy for the compiler writer.
But the FORTRAN-PL/I model requires a good deal of extra punctuation. It
also requires the CALL keyword, which, especially in subsystem
environments like CICS or any sort of GUI, can nearly make anyone trying
to read the code go blind.
Nobody in their right mind looks at the calls generated by the CICS preprocessor.
On 12/5/22 3:30 PM, Robin Vowels wrote:.
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote:
On 12/3/22 5:53 AM, Robin Vowels wrote:.
From: "gah4" <ga...@u.washington.edu>only a few reserved words makes the language harder to learn, because it >> forces to you memorize more exceptions.
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of >>> ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and >>> years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John] >> Yes, but you’re not required to writing such ridiculous code, and adding
On the other hand, running with zero reserved words, as with PL/I and
FORTRAN, or even with a merely minimal set, as in C, requires extra
keywords and punctuation (usually parentheses).
PL/I if x = 0 then
x = 1;
else do:
x = x + 2;
e = e + 1;
end;
In PL/I :
IF X = 0 THEN
DO; X = 1; END;
ELSE
DO;
X = X + 2; E = E + 1;
END;
and similarly in Fortran.
The bracketing is performed by keywords that are more easily seen than
the single character of curly braces.
.
C if (x == 0).
x = 1;
else {
x += 2;
e += 1;
}
Swift if x == 0 {
x = 1
} else {
x += 2
e += 1
These assignments can be written the same way in PL/I ,
but I prefer the traditional method.
.
}.
Honestly, in this, as in most matters, I like Swift best.
But Swift has one really neat trick when it comes to reserved words.
var `in` = 0
var out = 0
The backtick quotes make a reserved word safe for use as a name. (Swift >> has features comparable to PL/I GET and PUT DATA, so just changing the
name may not be feasible.)
In PL/I and Fortran, reserved words are safe for a name.
No, PL/I and FORTRAN don’t /have/ reserved words..
.Swift seems to be clumsy: you still need to keep in mind which words are keywords?
Languages should make it easy for the programmer, not easy for the compiler writer.
But the FORTRAN-PL/I model requires a good deal of extra punctuation..
It also requires the CALL keyword, which, especially in subsystem environments like CICS or any sort of GUI, can nearly make anyone trying.
to read the code go blind.
On Tuesday, December 6, 2022 at 12:18:55 PM UTC+11, John W. Kennedy wrote:
On 12/5/22 3:30 PM, Robin Vowels wrote:.
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote: >>>> On 12/3/22 5:53 AM, Robin Vowels wrote:
.From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
It seems, though, that languages are implemented a small number of
times, and used many times. So, designing for ease of use, instead of >>>>> ease of implementation makes more sense.
(Especially if you want a lot of people to want to use it.)
One feature that I find makes them easier to use, and harder to implement, is no reserved words.
For almost 50 years now, my favorite name for an otherwise unnamed
program is "this". (That is, where many people seem to use "foo", and >>>>> years before I knew about "foo".)
That worked fine, until Java came along with reserved word "this".
(Second choice, "that", fortunately isn't reserved in Java.)
[I take your point, but in PL/I you can say:
IF THEN = ELSE THEN BEGIN = IF; ELSE END = IF;
COBOL famously has too many reserved words but PL/I overreacted. -John] >>>> Yes, but you’re not required to writing such ridiculous code, and adding >>>> only a few reserved words makes the language harder to learn, because it >>>> forces to you memorize more exceptions.
On the other hand, running with zero reserved words, as with PL/I and
FORTRAN, or even with a merely minimal set, as in C, requires extra
keywords and punctuation (usually parentheses).
PL/I if x = 0 then
x = 1;
else do:
x = x + 2;
e = e + 1;
end;
In PL/I :
IF X = 0 THEN
DO; X = 1; END;
ELSE
DO;
X = X + 2; E = E + 1;
END;
and similarly in Fortran.
The bracketing is performed by keywords that are more easily seen than
the single character of curly braces.
.
C if (x == 0).
x = 1;
else {
x += 2;
e += 1;
}
Swift if x == 0 {
x = 1
} else {
x += 2
e += 1
These assignments can be written the same way in PL/I ,
but I prefer the traditional method.
.
}.
Honestly, in this, as in most matters, I like Swift best.
But Swift has one really neat trick when it comes to reserved words.
var `in` = 0
var out = 0
The backtick quotes make a reserved word safe for use as a name. (Swift >>>> has features comparable to PL/I GET and PUT DATA, so just changing the >>>> name may not be feasible.)
In PL/I and Fortran, reserved words are safe for a name.
No, PL/I and FORTRAN don’t /have/ reserved words..
I know that.
.
.Swift seems to be clumsy: you still need to keep in mind which words are keywords?
Languages should make it easy for the programmer, not easy for the compiler writer.
But the FORTRAN-PL/I model requires a good deal of extra punctuation..
Really? Where did you have in mind?
I like the words "TO" AND "BY" etc in DO statements.
They have the ability to be used in any order.
It also requires the CALL keyword, which, especially in subsystem.
environments like CICS or any sort of GUI, can nearly make anyone trying
to read the code go blind.
I like the word "CALL". It makes it obvious to the reader that a subroutine is being called.
On 12/6/22 1:52 AM, Robin Vowels wrote:.
On Tuesday, December 6, 2022 at 12:18:55 PM UTC+11, John W. Kennedy wrote:
On 12/5/22 3:30 PM, Robin Vowels wrote:
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote: >>>> On 12/3/22 5:53 AM, Robin Vowels wrote:
From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
.But the FORTRAN-PL/I model requires a good deal of extra punctuation..
Really? Where did you have in mind?
I like the words "TO" AND "BY" etc in DO statements.
They have the ability to be used in any order.
And on the F compiler, that actually meant something, but now the two expressions are evaluated in arbitrary order..
(Not to mention that the traditional from-to-step looping statement is increasingly absent from new languages, starting with Ada at the latest.)
However, I said "punctuation", as in the parentheses in
WHILE(expression), SELECT(expression), and many others.
It also requires the CALL keyword, which, especially in subsystem.
environments like CICS or any sort of GUI, can nearly make anyone trying >> to read the code go blind.
I like the word "CALL". It makes it obvious to the reader that a subroutine is being called.
On Wednesday, December 7, 2022 at 9:23:42 AM UTC+11, John W. Kennedy wrote:
On 12/6/22 1:52 AM, Robin Vowels wrote:.
On Tuesday, December 6, 2022 at 12:18:55 PM UTC+11, John W. Kennedy wrote: >>>> On 12/5/22 3:30 PM, Robin Vowels wrote:
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote: >>>>>> On 12/3/22 5:53 AM, Robin Vowels wrote:
From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
.But the FORTRAN-PL/I model requires a good deal of extra punctuation..
Really? Where did you have in mind?
I like the words "TO" AND "BY" etc in DO statements.
They have the ability to be used in any order.
And on the F compiler, that actually meant something, but now the two.
expressions are evaluated in arbitrary order.
(Not to mention that the traditional from-to-step looping statement is
increasingly absent from new languages, starting with Ada at the latest.)
However, I said "punctuation", as in the parentheses in
WHILE(expression), SELECT(expression), and many others.
"BY" and "TO" can be regarded as punctuation.
I don't see the parentheses in SELECT and WHILE as a problem.
They are only a pair of keystrokes.
.
It also requires the CALL keyword, which, especially in subsystem.
environments like CICS or any sort of GUI, can nearly make anyone trying >>>> to read the code go blind.
I like the word "CALL". It makes it obvious to the reader that a
subroutine is being called.
Robin Vowels <robin.vowels@gmail.com> wrote:
On Wednesday, December 7, 2022 at 9:23:42 AM UTC+11, John W. Kennedy wrote: >>> On 12/6/22 1:52 AM, Robin Vowels wrote:
.On Tuesday, December 6, 2022 at 12:18:55 PM UTC+11, John W. Kennedy wrote: >>>>> On 12/5/22 3:30 PM, Robin Vowels wrote:
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote: >>>>>>> On 12/3/22 5:53 AM, Robin Vowels wrote:
From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
.But the FORTRAN-PL/I model requires a good deal of extra punctuation. >>>> .Really? Where did you have in mind?
I like the words "TO" AND "BY" etc in DO statements.
They have the ability to be used in any order.
And on the F compiler, that actually meant something, but now the two.
expressions are evaluated in arbitrary order.
(Not to mention that the traditional from-to-step looping statement is
increasingly absent from new languages, starting with Ada at the latest.) >>>
However, I said "punctuation", as in the parentheses in
WHILE(expression), SELECT(expression), and many others.
"BY" and "TO" can be regarded as punctuation.
I don't see the parentheses in SELECT and WHILE as a problem.
They are only a pair of keystrokes.
OTOH, I don’t particularly care for C’s, and other languages, () in if statements.
.
It also requires the CALL keyword, which, especially in subsystem.
environments like CICS or any sort of GUI, can nearly make anyone trying >>>>> to read the code go blind.
I like the word "CALL". It makes it obvious to the reader that a
subroutine is being called.
On 12/7/22 1:01 PM, Peter Flass wrote:
Robin Vowels <robin.vowels@gmail.com> wrote:
On Wednesday, December 7, 2022 at 9:23:42 AM UTC+11, John W. Kennedy wrote: >>>> On 12/6/22 1:52 AM, Robin Vowels wrote:
.On Tuesday, December 6, 2022 at 12:18:55 PM UTC+11, John W. Kennedy wrote:
On 12/5/22 3:30 PM, Robin Vowels wrote:
On Sunday, December 4, 2022 at 6:54:54 AM UTC+11, John W. Kennedy wrote:
On 12/3/22 5:53 AM, Robin Vowels wrote:
From: "gah4" <ga...@u.washington.edu>
Date: Friday, 2 December 2022 11:18 AM
.But the FORTRAN-PL/I model requires a good deal of extra punctuation. >>>>> .Really? Where did you have in mind?
I like the words "TO" AND "BY" etc in DO statements.
They have the ability to be used in any order.
And on the F compiler, that actually meant something, but now the two.
expressions are evaluated in arbitrary order.
(Not to mention that the traditional from-to-step looping statement is >>>> increasingly absent from new languages, starting with Ada at the latest.) >>>>
However, I said "punctuation", as in the parentheses in
WHILE(expression), SELECT(expression), and many others.
"BY" and "TO" can be regarded as punctuation.
I don't see the parentheses in SELECT and WHILE as a problem.
They are only a pair of keystrokes.
OTOH, I don’t particularly care for C’s, and other languages, () in if >> statements.
Which is why modern C-related langages, such as Swift, eliminate them,
at the cost of mandating {...} pairs around single statements, as well
as groups. (But this avoids common errors when updating, anyway, so it’s seen as a plus, regardless.
My favorite complaint is about using REAL variables in DO loops.
Yes there are good reasons not to do it, but it isn't up to the language
to decide that.
The actual reason I follow this one, is that many (many!) years ago
I would sometimes translate BASIC programs to Fortran, where all
variables are Fortran REAL.
On Saturday, December 3, 2022 at 5:57:11 AM UTC-5, Robin Vowels wrote:
My favorite complaint is about using REAL variables in DO loops.
Yes there are good reasons not to do it, but it isn't up to the language
to decide that.
I disagree. Unless you know the details of your floating-point
hardware, you do not know how many times your loop will iterate if the
value is fractional (if it's integral and not too large, there is no problem). For example, on IEEE 754 hardware:
declare x(binary float);
do x = 0.0 repeat x + 0.1 while x <= 1.0;
...
end;
will iterate 11 times rather than the expected 10. It is better to ban binary-float loops rather than to allow this sort of bug. Subset G bans
all floating-point loops, as do many more recent languages.
The actual reason I follow this one, is that many (many!) years ago
I would sometimes translate BASIC programs to Fortran, where all
variables are Fortran REAL.
In that case, iterate thus:
declare i (fixed binary);
do i = 0 repeat i + 1 while i < 10;
x = i / 10;
...
end;
The book _The Elements of Programming Style_ by Brian Kernighan and P. J. Plauger discusses the pitfalls of counting with (binary) floating-point numbers in Chapter 6.
On Saturday, December 3, 2022 at 5:57:11 AM UTC-5, Robin Vowels wrote:
My favorite complaint is about using REAL variables in DO loops.
Yes there are good reasons not to do it, but it isn't up to the language
to decide that.
I disagree. Unless you know the details of your floating-point hardware, you do not know how many times your loop will iterate if the value is fractional (if it's integral and not too large, there is no problem). For example, on IEEE 754 hardware:
declare x(binary float);
do x = 0.0 repeat x + 0.1 while x <= 1.0;
...
end;
will iterate 11 times rather than the expected 10. It is better to ban binary-float loops rather than to allow this sort of bug. Subset G bans all floating-point loops, as do many more recent languages.
The actual reason I follow this one, is that many (many!) years ago
I would sometimes translate BASIC programs to Fortran, where all
variables are Fortran REAL.
In that case, iterate thus:
declare i (fixed binary);
do i = 0 repeat i + 1 while i < 10;
x = i / 10;
...
end;
The book _The Elements of Programming Style_ by Brian Kernighan and P. J. Plauger discusses the pitfalls of counting with (binary) floating-point numbers in Chapter 6.
That loop will iterate 11 times, even if you used DECIMAL FIXED, where
the fractional representation is exact. There is no bug here.
You have changed the exit criterion from "<=" to "<"!! I assume you
meant to keep it as "<=".
In particular, you might want a looping construct that does not require counting but a value assessment, particularly using some transcendental function. For such a loop, a floating point control variable would be ideally suited.
On Tuesday, February 28, 2023 at 1:23:38 PM UTC-5, David W Noon wrote:
In particular, you might want a looping construct that does not require
counting but a value assessment, particularly using some transcendental
function. For such a loop, a floating point control variable would be
ideally suited.
Can you give me an example?
In any case, the stricture in TEoPS is against *counting* with
floating-point numbers.
On Saturday, December 3, 2022 at 5:57:11 AM UTC-5, Robin Vowels wrote:.
My favorite complaint is about using REAL variables in DO loops.
Yes there are good reasons not to do it, but it isn't up to the language to decide that.
I disagree. Unless you know the details of your floating-point hardware, you do not know how many times your loop will iterate if the value is fractional (if it's integral and not too large, there is no problem). For example, on IEEE 754 hardware:.
declare x(binary float);
do x = 0.0 repeat x + 0.1 while x <= 1.0;.
...
end;
will iterate 11 times rather than the expected 10. It is better to ban binary-float loops rather than to allow this sort of bug. Subset G bans all floating-point loops, as do many more recent languages.
The actual reason I follow this one, is that many (many!) years agoIn that case, iterate thus:
I would sometimes translate BASIC programs to Fortran, where all
variables are Fortran REAL.
declare i (fixed binary);
do i = 0 repeat i + 1 while i < 10;,
x = i / 10;
...
end;
The book _The Elements of Programming Style_ by Brian Kernighan and P. J. Plauger discusses the pitfalls of counting with (binary) floating-point numbers in Chapter 6.
I did not write that; gah4 wrote it.
On Saturday, April 15, 2023 at 10:10:26 PM UTC-4, Robin Vowels wrote:
I did not write that; gah4 wrote it.
My apologies for the misattribution (and for making a balls of PL/I
syntax): I was distressed by the death of my wife two weeks earlier.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 343 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 31:26:19 |
| Calls: | 7,557 |
| Calls today: | 1 |
| Files: | 12,733 |
| Messages: | 5,655,716 |