2**X where X is negative is legal. 2**-X = 1/(2**X). 2**-17 = 0.076
A language might -- I am not an expert -- refuse N**2.0 where N was negative
because fractional powers of a negative number are illegal, and 2.0, as a
floating point number, could be seen as fractional.
Charles
I hope that he meant 2**X when X is negative. I checked some old Fortran
manuals and couldn't find anything about what is allowed on the left and right
hand side in foo**bar, except in constant expressions..
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
" Why won't FORTRAN square a negative number? Is this behavior peculiar to
FORTRAN?"
It did when I learned FORTRAN (circa 1971). Haven't touched FORTRAN in about 35
years.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Clark Morris
Sent: Thursday, July 18, 2019
[Default] On 18 Jul 2019 09:42:13 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:
>On Tue, 16 Jul 2019 19:22:51 +, Seymour J Metz wrote:
>>
>>The cardinal sin in language design is to make the compiler simpler at the
>>expense of the
I refer to such helpful operators as "Molly Malone", from "She of a faever,
from which none could save her, and that was the end of sweet Molly Malone".
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on
Which EBCDIC code page?
Brackets (ASCII 5B and 5D) are not in the same position for all EBCDIC code
pages. The important ones are:
037
BA
BB
1047
AD
BD
I don't know where they are
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
On Thu, 18 Jul 2019 16:51:57 +, Seymour J Metz wrote:
>OOREXX now allows the equivalent of expressions in tails:
>
> stem[tail expression]
>
What are those strange characters, "[" and "]"? What are their EBCDIC code
points?
>If X is a floating point (REAL) variable, why shouldn't x**(-1)
Implicit conversion is always problematical; you're damned if you do and damned
if you don't. The tradeoff in PL/I was in favor of expressive power, and I sort
of agree, although experience with Ada has given me an appreciation of strict
typing.
--
Shmuel (Seymour J.) Metz
OOREXX now allows the equivalent of expressions in tails:
stem[tail expression]
If X is a floating point (REAL) variable, why shouldn't x**(-1) be legal?
A for using a floating point variable as a control variable, I have no
sympathy. In the real world, measuring devices have errors and you
On Tue, 16 Jul 2019 19:22:51 +, Seymour J Metz wrote:
>
>The cardinal sin in language design is to make the compiler simpler at the
>expense of the user. ...
>
I see a notable example of this in Rexx's not supporting expressions in compound
symbol tails which some have justified as making
On 7/17/19 9:55 AM, David Crayford wrote:
On 2019-07-16 4:44 AM, Tom Marchant wrote:
Some C programmers are fond of if (7 == foo) rather than the more
conventional if (foo == 7) because if one gets in the habit of doing
so and then accidentally codes if (7 = foo) one gets a compile error
On Wed, 17 Jul 2019 23:59:04 +0200, Bernd Oppolzer wrote:
>
>One program had a coding like this:
>
> IF 9 < ZZ < 20 THEN DO;
> ...
There's an argument here for strong typing, prohibiting comparing
a boolean to a numeric without a cast.
> ... Obviously this is not what the coder intended;
Am 17.07.2019 um 19:54 schrieb Paul Gilmartin:
On Wed, 17 Jul 2019 12:22:35 -0400, Steve Smith wrote:
The original sin was making "=" the assignment operator. I guess we can
blame that on FORTRAN, and it must make mathematicians cringe still.
I once (ca. 1967) needed to enlighten and
On Wed, 17 Jul 2019 12:22:35 -0400, Steve Smith wrote:
>The original sin was making "=" the assignment operator. I guess we can
>blame that on FORTRAN, and it must make mathematicians cringe still.
>
I once (ca. 1967) needed to enlighten and disillusion a naive
but persistent physics graduate
Ken Iverson, the inventor of APL differentiated also between the "-" as an
operator
And the "-" as the sign of a negative number.
http://www.softwarepreservation.org/projects/apl/Books/APROGRAMMING%20LANGUAGE
best regards
Mike
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion
On Wed, Jul 17, 2019 at 11:59 AM Seymour J Metz wrote:
> That's an excuse for Fortran, but PL/I already used colons, so why not :=?
>
I will go even farther that than. In today's world, especially outside of
the z Series, I would prefer the APL assignment character: ← Of course,
that is not on
That's an excuse for Fortran, but PL/I already used colons, so why not :=?
By the time C came along that excuse was even less viable.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
John
On Wed, Jul 17, 2019 at 11:23 AM Steve Smith wrote:
> The original sin was making "=" the assignment operator. I guess we can
> blame that on FORTRAN, and it must make mathematicians cringe still.
>
I haven't said anything, but I think you're correct. Of course, in the "bad
old days" of punch
> A somewhat complementary sin is to enrich the facilities of the language
> to the benefit of the sophisticated user but to the detriment of the naive
> user.
If by "enrich" you mean to change the semantics of existing code, then that is
not to the benefit of the sophisticated user.
The original sin was making "=" the assignment operator. I guess we can
blame that on FORTRAN, and it must make mathematicians cringe still.
sas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
On 2019-07-16 4:44 AM, Tom Marchant wrote:
Some C programmers are fond of if (7 == foo) rather than the more conventional
if (foo == 7) because if one gets in the habit of doing so and then
accidentally codes if (7 = foo) one gets a compile error rather than unexpected
behavior.
For those
https://en.wikipedia.org/wiki/Pascal_MicroEngine
In a message dated 7/16/2019 6:02:25 PM Central Standard Time,
bernd.oppol...@t-online.de writes:
and Pascal :-)
Pascal makes the same difference between := (assignment) and = (comparison)
So does C.
On Tue, 16 Jul 2019 22:36:43 +0200, Bernd Oppolzer wrote:
>>>
>>> I added BREAK, CONTINUE, RETURN, MODULE, LOCAL and STATIC;
>>> this was in the years from 2011 to 2016. No more need since.
>>>
>> I've done many of these as predefined quasi-identifiers, similar to Pascal's
>> predefined standard
Am 16.07.2019 um 22:16 schrieb Paul Gilmartin:
On Tue, 16 Jul 2019 21:37:38 +0200, Bernd Oppolzer wrote:
Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
On Tue, 16 Jul 2019 21:37:38 +0200, Bernd Oppolzer wrote:
>Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
>>> Furthermore: the more modern languages like Pascal, C and Java etc.
>>> forbid the use of reserved symbols as variable names. This may be
>>> restrictive, but makes the compilers much
Am 16.07.2019 um 21:22 schrieb Seymour J Metz:
Furthermore: the more modern languages like Pascal, C and Java etc.
forbid the use of reserved symbols as variable names. This may be
restrictive, but makes the compilers much much simpler.
The cardinal sin in language design is to make the
> Furthermore: the more modern languages like Pascal, C and Java etc.
> forbid the use of reserved symbols as variable names. This may be
> restrictive, but makes the compilers much much simpler.
The cardinal sin in language design is to make the compiler simpler at the
expense of the user. An
Space is permitted almost everywhere in PL/1,
not in the middle of identifiers (in contrast to FORTRAN).
It is permitted before the left paranthesis of subscripts,
so there is no chance for the compiler to decide before
the semicolon or THEN in this case:
IF (possible index expr1) =
> Hmmm ... the only feature that Pascal lacks IMO is call-by-name,
Labels in Pascal are more like Fortran than Algol; strictly numeric. Prior to
the ISO standard, you didn't have conformant array parameters, which made Pasal
almost useless for handling arrays.
As to call by name, it's
Am 16.07.2019 um 20:40 schrieb Seymour J Metz:
Pascal makes the same difference between := (assignment) and = (comparison)
Pascal is a castrated version of Algol 60,
Hmmm ... the only feature that Pascal lacks IMO is call-by-name,
but this is something not easy to understand (and explain) to
> Pascal makes the same difference between := (assignment) and = (comparison)
Pascal is a castrated version of Algol 60,
> So does C.
You're missing Charles Mills's point; in C it is easy to type "=" where you
meant "=="; typing ":=" when you meant "=" is much less likely.
--
Shmuel
AFAIK a space is not permitted in PL/I between an identifier and the left
parenthesis for the subscripts. If that is correct then
IF (1) = (2);
can easily be recognized as an IF statement.
Id do, however, agree that it is very bad form to knowingly use a keyword as an
identifier.
--
and Pascal :-)
Pascal makes the same difference between := (assignment) and = (comparison)
So does C.
BTW: a free Pascal compiler for mainframe targets:
http://bernd-oppolzer.de/job9.htm
https://www.facebook.com/StanfordPascal
https://github.com/StanfordPascal/Pascal
unfortunately only AMODE 24
This double meaning of =, together with the absence of reserved words
makes PL/1 parsing extremely hard. Consider for example
IF (1) = (2);
now what does that mean?
Given a declaration
DCL IF (25) BIN FIXED (31);
that is, if IF is an array of integers, the "IF" statement above is a
valid
One of the things that I liked about Algol was that "=" was always a comparison
operator; assignment was ":=". But even in PL/I that particular error is
impossible: the "=" in "IF foo=bar" can never be interpreted as assignment.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
*Some* compilers generate a warning. if (foo = bar) ... is almost certainly an
error, and if it is not, you can code it as if ((foo = bar) != 0) ... or
several other ways.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of
On Mon, 15 Jul 2019 13:30:51 -0700, Charles Mills wrote:
>Some C programmers are fond of if (7 == foo) rather than the more conventional
>if (foo == 7) because if one gets in the habit of doing so and then
>accidentally codes if (7 = foo) one gets a compile error rather than
>unexpected
Some C programmers are fond of if (7 == foo) rather than the more conventional
if (foo == 7) because if one gets in the habit of doing so and then
accidentally codes if (7 = foo) one gets a compile error rather than unexpected
behavior.
For those not familiar with C, foo == 7 is a relational
38 matches
Mail list logo
