I'm getting close to the end of creating my LRM for Subset G, and I've
been looking at features excluded from Subset G that I think might be
Good Things to add to the pli2c compiler I am thinking about.
Here's a list in no particular order. Feedback on the (apparent or
actual) utility of these would be appreciated.
Language features:
1. BYVALUE option to specify non-pointer arguments to C functions.
2. DO loops with DOWNTHRU/UPTHRU (needed with UNSIGNED).
3. OPTIONS(MAIN) for sure, and possibly OPTIONS(WINMAIN), but does
writing Windows client apps in PL/I make sense any more?
4. INLINE/NOINLINE on PROCEDURE statements (encourages inlining but does not force it).
5. REDUCIBLE/IRREDUCIBLE on PROCEDURE statements. (Indicates the
procedure is pure: it has no side effects and its returned value depends
only on its arguments. Passed through to gcc.)
6. Non-integer FIXED BINARY values.
7. Complex numbers (FLOAT only, maybe BINARY FLOAT only)
8. UNSIGNED declaration (for FIXED BINARY only, C compatibility).
9. ATTENTION condition (Control-C or equivalent).
Files:
10. ENVIRONMENT(APPEND) to indicate opening a stream file for append only.
11. Protection options when creating a file (ignore if file already
exists, or change them?)
12. Transactions on indexed sequential files (other files are unaffected).
13. ENVIRONMENT(CARRIAGE_RETURN_FORMAT) to specify LF or CRLF when writing stream files.
14. ENVIRONMENT(DELETE) on OPEN or CLOSE: file is deleted when closed.
15. ENVIRONMENT(DEFAULT_DIRECTORY): specified on OPEN. Not the same as chdir() because not sticky.
16. DISPLAY statement with REPLY option: for convenient interactive I/O.
17. Allow suppressing echo and special-character processing on the terminal during GET.
18. PROMPT option on interactive GET.
19. Specify key matching other than equality on indexed sequential files.
20. ENVIRONMENT(MAXIMUM_RECORD_SIZE) for direct files, since Unix/Windows environments don't have such a concept.
21. OPTIONS(SCALARVARYING).
22. ENVIRONMENT(IGNORE_LINE_MARKS) to ignore end-of-line in GET LIST.
6. Non-integer FIXED BINARY values.
As for 22, stream I/O is supposed to be ignoring line boundaries anyway.
John Cowan <cowan@ccil.org> wrote:
I'm getting close to the end of creating my LRM for Subset G, and I've
been looking at features excluded from Subset G that I think might be
Good Things to add to the pli2c compiler I am thinking about.
Here's a list in no particular order. Feedback on the (apparent or
actual) utility of these would be appreciated.
Language features:
1. BYVALUE option to specify non-pointer arguments to C functions.
2. DO loops with DOWNTHRU/UPTHRU (needed with UNSIGNED).
3. OPTIONS(MAIN) for sure, and possibly OPTIONS(WINMAIN), but does
writing Windows client apps in PL/I make sense any more?
4. INLINE/NOINLINE on PROCEDURE statements (encourages inlining but does not force it).
5. REDUCIBLE/IRREDUCIBLE on PROCEDURE statements. (Indicates the
procedure is pure: it has no side effects and its returned value depends
only on its arguments. Passed through to gcc.)
6. Non-integer FIXED BINARY values.
7. Complex numbers (FLOAT only, maybe BINARY FLOAT only)
8. UNSIGNED declaration (for FIXED BINARY only, C compatibility).
9. ATTENTION condition (Control-C or equivalent).
Files:
10. ENVIRONMENT(APPEND) to indicate opening a stream file for append only. >>
11. Protection options when creating a file (ignore if file already
exists, or change them?)
12. Transactions on indexed sequential files (other files are unaffected). >>
13. ENVIRONMENT(CARRIAGE_RETURN_FORMAT) to specify LF or CRLF when writing stream files.
14. ENVIRONMENT(DELETE) on OPEN or CLOSE: file is deleted when closed.
15. ENVIRONMENT(DEFAULT_DIRECTORY): specified on OPEN. Not the same as
chdir() because not sticky.
16. DISPLAY statement with REPLY option: for convenient interactive I/O.
17. Allow suppressing echo and special-character processing on the terminal during GET.
18. PROMPT option on interactive GET.
19. Specify key matching other than equality on indexed sequential files.
20. ENVIRONMENT(MAXIMUM_RECORD_SIZE) for direct files, since Unix/Windows
environments don't have such a concept.
21. OPTIONS(SCALARVARYING).
22. ENVIRONMENT(IGNORE_LINE_MARKS) to ignore end-of-line in GET LIST.
6-10 and 16. Iron Spring PL/I implements 16 as ENV(CRLF), LF, or CR. I also have ENV(TEXT) that I got from somewhere, probably Multics.
For DISPLAY, I use $ at the end of the displayed line to suppress the training carriage return. If I’d done a bit more research I would have found that PL/I on TSO uses : for that purpose, and gone with that.
As for 22, stream I/O is supposed to be ignoring line boundaries anyway.
On Saturday, September 10, 2022 at 2:14:29 PM UTC-4, bearlyabus...@gmail.com wrote:
6. Non-integer FIXED BINARY values.
I'm looking at two different C libraries. Here's what they provide:
jcarrano/fixed_point_arith:
FIXED BINARY(15,15); (31,30); (15,8); (31,15)
Supports arithmetic and comparisons
AVRfix:
FIXED BINARY(31,16); (31,24); (15,8)
Supports arithmetic and comparisons
Supports abs, round, shift, countls, sqrt, sin, cos, tan, atan2, log
I'd be interested to know what other systems provide.
As for 22, stream I/O is supposed to be ignoring line boundaries anyway.
That would be the default: the idea is to have a mode in which line marks act as a terminator, instead of pretending that we are reading punched cards.
On Saturday, September 10, 2022 at 2:14:29 PM UTC-4, bearlyabus...@gmail.com wrote:
6. Non-integer FIXED BINARY values.
I'm looking at two different C libraries. Here's what they provide:
jcarrano/fixed_point_arith:
FIXED BINARY(15,15); (31,30); (15,8); (31,15)
Supports arithmetic and comparisons
AVRfix:
FIXED BINARY(31,16); (31,24); (15,8)
Supports arithmetic and comparisons
Supports abs, round, shift, countls, sqrt, sin, cos, tan, atan2, log
I'd be interested to know what other systems provide.
As for 22, stream I/O is supposed to be ignoring line boundaries anyway.
That would be the default: the idea is to have a mode in which line marks
act as a terminator, instead of pretending that we are reading punched cards.
As it is, G is fundamentally incompatible with real PL/I on this point.
If you add these, you’ll be creating a third version equally
incompatible with both.
What about CONTROLLED memory?
On Saturday, September 10, 2022 at 8:06:44 PM UTC-4, John W. Kennedy wrote:.
As it is, G is fundamentally incompatible with real PL/I on this point.I'm not sure which point you mean. You can of course specify any FIXED BIN numbers you want up to the given limits.
If you add these, you’ll be creating a third version equally incompatible with both.What "real" PL/I? There are already a lot of versions: z/OS, IBM OS/2, VOS, Kednos, Iron Spring, .... In any case, the pli2c compiler will have compile-time switches to enable these features, so by default it is a straightforward Subset G compiler.
On Saturday, September 10, 2022 at 11:22:17 PM UTC-4, mike...@gmail.com wrote:
What about CONTROLLED memory?
The Subset G committee wrote in Appendix F: "CONTROLLED is excluded because it is largely redundant with BASED."
On Sunday, September 11, 2022 at 2:11:44 PM UTC+10, co...@ccil.org wrote:
On Saturday, September 10, 2022 at 8:06:44 PM UTC-4, John W. Kennedy wrote:
As it is, G is fundamentally incompatible with real PL/I on this point.I'm not sure which point you mean. You can of course specify any FIXED BIN numbers you want up to the given limits.
If you add these, you’ll be creating a third version equally incompatible with both.What "real" PL/I? There are already a lot of versions: z/OS, IBM OS/2, VOS, Kednos, Iron Spring, .... In any case, the pli2c compiler will have compile-time switches to enable these features, so by default it is a straightforward Subset G compiler.
On Saturday, September 10, 2022 at 11:22:17 PM UTC-4, mike...@gmail.com wrote:
What about CONTROLLED memory?
The Subset G committee wrote in Appendix F: "CONTROLLED is excluded because it is largely redundant with BASED.".
They didn't know what they were talking about.
воскресенье, 11 сентября 2022 г. в 12:01:17 UTC+3, Robin Vowels:.
On Sunday, September 11, 2022 at 2:11:44 PM UTC+10, co...@ccil.org wrote:
On Saturday, September 10, 2022 at 8:06:44 PM UTC-4, John W. Kennedy wrote:
As it is, G is fundamentally incompatible with real PL/I on this point.I'm not sure which point you mean. You can of course specify any FIXED BIN numbers you want up to the given limits.
If you add these, you’ll be creating a third version equally incompatible with both.What "real" PL/I? There are already a lot of versions: z/OS, IBM OS/2, VOS, Kednos, Iron Spring, .... In any case, the pli2c compiler will have compile-time switches to enable these features, so by default it is a straightforward Subset G compiler.
On Saturday, September 10, 2022 at 11:22:17 PM UTC-4, mike...@gmail.com wrote:
What about CONTROLLED memory?
The Subset G committee wrote in Appendix F: "CONTROLLED is excluded because it is largely redundant with BASED.".
They didn't know what they were talking about.
What about PUT (GET) DATA;.
Also for arrays with variable bounds BASED is not alternative for CONTROLLED
They didn't know what they were talking about.
On 9/11/22 12:11 AM, John Cowan wrote:
On Saturday, September 10, 2022 at 8:06:44 PM UTC-4, John W. Kennedy wrote: >>
As it is, G is fundamentally incompatible with real PL/I on this point.
I'm not sure which point you mean. You can of course specify any FIXED
BIN numbers you want up to the given limits.
If you add these, you’ll be creating a third version equally
incompatible with both.
What "real" PL/I? There are already a lot of versions: z/OS, IBM OS/2,
VOS, Kednos, Iron Spring, .... In any case, the pli2c compiler will
have compile-time switches to enable these features, so by default it is
a straightforward Subset G compiler.
If you have two PL/I compilers, and the very same short, simple code is submitted to both, and compilers without error, but utterly different
results are produced, at least one of them isn’t real PL/I.
Subset G grossly alters the entire meaning of fixed-point-binary division.
On Saturday, September 10, 2022 at 11:22:17 PM UTC-4, mike...@gmail.com wrote:
What about CONTROLLED memory?
The Subset G committee wrote in Appendix F: "CONTROLLED is excluded
because it is largely redundant with BASED."
Also very useful looks construction GET/PUT STRING
On Sunday, September 11, 2022 at 5:01:17 AM UTC-4, Robin Vowels wrote:...
They didn't know what they were talking about.
About 36 members of CBEMA (now ITIC) sent representatives, so there was certainly a wide scope of participants, however much or little any of them contributed.
On Saturday, September 10, 2022 at 8:06:44 PM UTC-4, John W. Kennedy wrote:
As it is, G is fundamentally incompatible with real PL/I on this point.
I'm not sure which point you mean. You can of course specify any FIXED BIN numbers you want up to the given limits.
If you add these, you’ll be creating a third version equally
incompatible with both.
What "real" PL/I? There are already a lot of versions: z/OS, IBM OS/2, VOS, Kednos, Iron Spring, .... In any case, the pli2c compiler will have compile-time switches to enable these features, so by default it is a straightforward Subset G compiler.
On Saturday, September 10, 2022 at 11:22:17 PM UTC-4, mike...@gmail.com wrote:
What about CONTROLLED memory?
The Subset G committee wrote in Appendix F: "CONTROLLED is excluded because it is largely redundant with BASED."
John W Kennedy <john.w.kennedy@gmail.com> wrote:
On 9/11/22 12:11 AM, John Cowan wrote:
On Saturday, September 10, 2022 at 8:06:44 PM UTC-4, John W. Kennedy wrote: >>>
As it is, G is fundamentally incompatible with real PL/I on this point. >>>I'm not sure which point you mean. You can of course specify any FIXED
BIN numbers you want up to the given limits.
If you add these, you’ll be creating a third version equally
incompatible with both.
What "real" PL/I? There are already a lot of versions: z/OS, IBM OS/2,
VOS, Kednos, Iron Spring, .... In any case, the pli2c compiler will
have compile-time switches to enable these features, so by default it is >>> a straightforward Subset G compiler.
If you have two PL/I compilers, and the very same short, simple code is
submitted to both, and compilers without error, but utterly different
results are produced, at least one of them isn’t real PL/I.
Subset G grossly alters the entire meaning of fixed-point-binary division.
Once again, this isn’t hard to implement with a certain amount of shifting, although binary fractions blew my mind at first. It’s the conversion between binary and decimal that’s not easy.
Yes, but you asked us about proposals for today's state, but this is argument from 1981!
Subset G grossly alters the entire meaning of fixed-point-binary division.
On Sunday, September 11, 2022 at 2:46:46 PM UTC-4, John W. Kennedy wrote:.
Subset G grossly alters the entire meaning of fixed-point-binary division.Okay, let's see if I understand. You are saying that a program in which all FIXED BINARY(p, q) variables are declared with q = 0 will behave differently in "real PL/I" than in Subset G.
Can you give me an example so I can understand further? (Of course, if there are any variables where q <> 0, then a Subset G compiler will not compile the code at all.)
Peter Flass <peter...@yahoo.com> wrote:.
John W Kennedy <john.w....@gmail.com> wrote:
On 9/11/22 12:11 AM, John Cowan wrote:
On Saturday, September 10, 2022 at 8:06:44 PM UTC-4, John W. Kennedy wrote:
As it is, G is fundamentally incompatible with real PL/I on this point. >>>I'm not sure which point you mean. You can of course specify any FIXED >>> BIN numbers you want up to the given limits.
If you add these, you’ll be creating a third version equally
incompatible with both.
What "real" PL/I? There are already a lot of versions: z/OS, IBM OS/2, >>> VOS, Kednos, Iron Spring, .... In any case, the pli2c compiler will
have compile-time switches to enable these features, so by default it is >>> a straightforward Subset G compiler.
If you have two PL/I compilers, and the very same short, simple code is >> submitted to both, and compilers without error, but utterly different
results are produced, at least one of them isn’t real PL/I.
Subset G grossly alters the entire meaning of fixed-point-binary division.
Once again, this isn’t hard to implement with a certain amount of shifting,
although binary fractions blew my mind at first. It’s the conversion between binary and decimal that’s not easy.
On further reflection, I think this was dropped from the subset because of its limited utility. If OP’s intent is to implement a Subset G compiler, this can be dispensed with, and, indeed, the closer he sticks to the standard the better.
My original plan was compatibility with “F” and 2.3, so I included a lot of
stuff that isn’t particularly useful. Right now I have re-read material on adjustable BASED storage and am working on implementing it. If it were my decision, I would have done things differently than the standard. Research and testing on various compilers I have access to has been eye-opening.
As I’ve gone along, I’ve plugged in useful features from various compilers.
Based on what I’ve seen on new compiler features, my personal opinion is that IBM has now gone off the deep end and is now sticking in everything
but the kitchen sink.
On Sunday, September 11, 2022 at 5:01:17 AM UTC-4, Robin Vowels wrote:.
They didn't know what they were talking about.From the standard:
Technical Committee X3J1 had the following members at the time it forwarded this standard to its parent committee:
John C. Klensin, Chair
Charles G. (Chip) Nylander, Vice Chair
Fidelis N. Umeh, Secretary
Alex J. Arthur, Editor (deceased)
David R. Morey, Editor
George H. Royer, Editor
Davinder Athwal
Keith Besaw
Fred Calm
Arthur W. Coston
Andre Lacroix
Kam Mok
Kevin Mooney
Beverly Schultz
Nancy Travis
J. G. Van Stee
Others who made important contributions to this standard were:
Paul W. Abrahams
Kenneth Dritz
Andrei P. Ershov
A. Craig Franklin
Mimi Gerstell
Ev M. Greene
Richard Howells
L. Korneva
Peter Krupp
John Leffler
Howell A. (Skip) Richards
Gary Roberts
David Sahakian
W. Olin Sibert
Anthony P. Smith
Haruyuki Takeda
Richard Weaver
[end quote]
About 36 members of CBEMA (now ITIC) sent representatives, so there was certainly a wide scope of participants, however much or little any of them contributed.
The other is about whether the Committee that wrote Subset G knew what they were doing..
But your citation is not right! Because CONTROLLED is a lot more convenient for
varying bounds array.
I can imagine that realisation of CONTROLLED is complex,.
and it's a primary reason.
The other is about whether the Committee that wrote Subset G knew what they were doing.
But your citation is not right! Because CONTROLLED is a lot more
convenient for varying bounds array. I can imagine that realisation of CONTROLLED is complex, and it's a primary reason.
I'm getting close to the end of creating my LRM for Subset G, and I've been looking at features excluded from Subset G that I think might be Good Things to add to the pli2c compiler I am thinking about..
Here's a list in no particular order. Feedback on the (apparent or actual) utility of these would be appreciated.
Language features:
1. BYVALUE option to specify non-pointer arguments to C functions.
2. DO loops with DOWNTHRU/UPTHRU (needed with UNSIGNED).
3. OPTIONS(MAIN) for sure, and possibly OPTIONS(WINMAIN), but does writing Windows client apps in PL/I make sense any more?
4. INLINE/NOINLINE on PROCEDURE statements (encourages inlining but does not force it).
5. REDUCIBLE/IRREDUCIBLE on PROCEDURE statements. (Indicates the procedure is pure: it has no side effects and its returned value depends only on its arguments. Passed through to gcc.)
6. Non-integer FIXED BINARY values.
7. Complex numbers (FLOAT only, maybe BINARY FLOAT only)
8. UNSIGNED declaration (for FIXED BINARY only, C compatibility).
9. ATTENTION condition (Control-C or equivalent).
Files:
10. ENVIRONMENT(APPEND) to indicate opening a stream file for append only.
11. Protection options when creating a file (ignore if file already exists, or change them?)
12. Transactions on indexed sequential files (other files are unaffected).
13. ENVIRONMENT(CARRIAGE_RETURN_FORMAT) to specify LF or CRLF when writing stream files.
14. ENVIRONMENT(DELETE) on OPEN or CLOSE: file is deleted when closed.
15. ENVIRONMENT(DEFAULT_DIRECTORY): specified on OPEN. Not the same as chdir() because not sticky.
16. DISPLAY statement with REPLY option: for convenient interactive I/O.
17. Allow suppressing echo and special-character processing on the terminal during GET.
18. PROMPT option on interactive GET.
19. Specify key matching other than equality on indexed sequential files.
20. ENVIRONMENT(MAXIMUM_RECORD_SIZE) for direct files, since Unix/Windows environments don't have such a concept.
21. OPTIONS(SCALARVARYING).
22. ENVIRONMENT(IGNORE_LINE_MARKS) to ignore end-of-line in GET LIST.
On Saturday, September 10, 2022 at 2:14:29 PM UTC-4, bearlyabus...@gmail.com wrote:.
I'm looking at two different C libraries. Here's what they provide:6. Non-integer FIXED BINARY values.
jcarrano/fixed_point_arith:
FIXED BINARY(15,15); (31,30); (15,8); (31,15)
Supports arithmetic and comparisons
AVRfix:
FIXED BINARY(31,16); (31,24); (15,8)
Supports arithmetic and comparisons
Supports abs, round, shift, countls, sqrt, sin, cos, tan, atan2, log
I'd be interested to know what other systems provide.
As for 22, stream I/O is supposed to be ignoring line boundaries anyway.That would be the default: the idea is to have a mode in which line marks act as a terminator,
instead of pretending that we are reading punched cards..
On Sunday, September 11, 2022 at 2:46:46 PM UTC-4, John W. Kennedy wrote:course, if there are any variables where q <> 0, then a Subset G compiler will not compile the code at all.)
Subset G grossly alters the entire meaning of fixed-point-binary division.
Okay, let's see if I understand. You are saying that a program in which all FIXED BINARY(p, q) variables are declared with q = 0 will behave differently in "real PL/I" than in Subset G. Can you give me an example so I can understand further? (Of
In G, any fixed-binary divide gives an integer result. In real PL/I,
apart from a few pathological cases, it gives an integer/fraction result.
On Tuesday, September 13, 2022 at 11:06:39 PM UTC-4, John W. Kennedy wrote:.
In G, any fixed-binary divide gives an integer result. In real PL/I,I see. So in full PL/I, if it's assigned to another FIXED BIN (with q = 0), it'll get truncated. But if it gets dropped into a FIXED DECIMAL or something else, then you are going to get the fraction bits.
apart from a few pathological cases, it gives an integer/fraction result.
Or are you? That seems to contract what Robin said, that if all FIXED BIN variables are q = 0, there is no difference between Subset G and full PL/I.
I have yet to understand the Subset G interpreter, especially anything to do with conversion.
On Tuesday, September 13, 2022 at 11:06:39 PM UTC-4, John W. Kennedy wrote:
In G, any fixed-binary divide gives an integer result. In real PL/I,
apart from a few pathological cases, it gives an integer/fraction result.
I see. So in full PL/I, if it's assigned to another FIXED BIN (with q =
0), it'll get truncated. But if it gets dropped into a FIXED DECIMAL or something else, then you are going to get the fraction bits.
Or are you? That seems to contract what Robin said, that if all FIXED BIN variables are q = 0, there is no difference between Subset G and full PL/I.
I have yet to understand the Subset G interpreter, especially anything to
do with conversion.
On Tuesday, September 13, 2022 at 11:06:39 PM UTC-4, John W. Kennedy wrote:
In G, any fixed-binary divide gives an integer result. In real PL/I,
apart from a few pathological cases, it gives an integer/fraction result.
I see. So in full PL/I, if it's assigned to another FIXED BIN (with q = 0), it'll get truncated. But if it gets dropped into a FIXED DECIMAL or something else, then you are going to get the fraction bits.
Or are you? That seems to contract what Robin said, that if all FIXED BIN variables are q = 0, there is no difference between Subset G and full PL/I.
I have yet to understand the Subset G interpreter, especially anything to do with conversion.
So you're saying that 3 / 2 is an integer?
On Wednesday, September 14, 2022 at 2:30:49 PM UTC-4, John W. Kennedy wrote:. Under RULES(IBM), a/b yields precision (31,15).
So you're saying that 3 / 2 is an integer?By no means. Here is a concrete example (and please forgive any typos):
procedure foo;
declare a fixed binary(15,0) initial 3;
declare b fixed binary(15,0) initial 2;
declare c1 fixed binary(15,0);
declare c2 fixed binary(7, 8);
declare d fixed decimal(2,1);
c1 = a / b;
c2 = a / b;. all ditto.
d = a / b;. all ditto.
end;.
Now plainly the value of C1 is 1, because that's all there's room for. What are the values of C2 and D?
Are they also 1, or are they approximately 1.5
and exactly 1.5 respectively?.
In other words, does the type on the left side of the assignment affect the evaluation of the expression on the right side?.
Furthermore, I don't see what difference it makes whether 15 is the maximum number of bits available for a FIXED BIN or not..
On 9/14/22 12:03 AM, John Cowan wrote:.
On Tuesday, September 13, 2022 at 11:06:39 PM UTC-4, John W. Kennedy wrote:
In G, any fixed-binary divide gives an integer result. In real PL/I,
apart from a few pathological cases, it gives an integer/fraction result.
I see. So in full PL/I, if it's assigned to another FIXED BIN (with q = 0), it'll get truncated. But if it gets dropped into a FIXED DECIMAL or something else, then you are going to get the fraction bits.
Or are you? That seems to contract what Robin said, that if all FIXED BIN variables are q = 0, there is no difference between Subset G and full PL/I.
So you're saying that 3 / 2 is an integer?.
On Thursday, September 15, 2022 at 4:30:49 AM UTC+10, John W. Kennedy wrote:
On 9/14/22 12:03 AM, John Cowan wrote:.
On Tuesday, September 13, 2022 at 11:06:39 PM UTC-4, John W. Kennedy wrote: >>>
In G, any fixed-binary divide gives an integer result. In real PL/I,I see. So in full PL/I, if it's assigned to another FIXED BIN (with q = 0), it'll get truncated. But if it gets dropped into a FIXED DECIMAL or something else, then you are going to get the fraction bits.
apart from a few pathological cases, it gives an integer/fraction result. >>>
Or are you? That seems to contract what Robin said, that if all FIXED BIN variables are q = 0, there is no difference between Subset G and full PL/I.
So you're saying that 3 / 2 is an integer?.
3/2 is always 1.5, with precision (15,14)
On 9/14/22 9:55 PM, Robin Vowels wrote:.
On Thursday, September 15, 2022 at 4:30:49 AM UTC+10, John W. Kennedy wrote:
On 9/14/22 12:03 AM, John Cowan wrote:.
On Tuesday, September 13, 2022 at 11:06:39 PM UTC-4, John W. Kennedy wrote:
In G, any fixed-binary divide gives an integer result. In real PL/I, >>>> apart from a few pathological cases, it gives an integer/fraction result.
I see. So in full PL/I, if it's assigned to another FIXED BIN (with q = 0), it'll get truncated. But if it gets dropped into a FIXED DECIMAL or something else, then you are going to get the fraction bits.
Or are you? That seems to contract what Robin said, that if all FIXED BIN variables are q = 0, there is no difference between Subset G and full PL/I.
So you're saying that 3 / 2 is an integer?.
3/2 is always 1.5, with precision (15,14)
ot in Subset G, because in G, all FIXED BINARY variables are (p,0).
Fixed-point arithmetic has been a booby trap for language designers from.
the beginning.
COBOL completely screwed the pooch, although it added an
option to get it almost right at the turn of the century. PL/I got it
almost right, but Subset G broke it (though only in binary). Ada finally
got it right, and PL/I could be improved by changing {FIXED|FLOAT} to {FIXED|FLOAT|INTEGER}, but it’s not going to happen. Most languages, of course, have given up, and only have float and integer. I half suspect
more languages today have a rational type than a decently designed fixed-point.
Are you not aware that 3/2 is a DECIMAL expression that evaluates
to 1.5, with precision (15,14) ?
Fixed-point arithmetic has been a booby trap for language designers from.
the beginning.
Certainly, if you think that 3/2 is a binary expression.
.--
COBOL completely screwed the pooch, although it added an
option to get it almost right at the turn of the century. PL/I got it
almost right, but Subset G broke it (though only in binary). Ada finally
got it right, and PL/I could be improved by changing {FIXED|FLOAT} to
{FIXED|FLOAT|INTEGER}, but it’s not going to happen. Most languages, of
course, have given up, and only have float and integer. I half suspect
more languages today have a rational type than a decently designed
fixed-point.
.Are you not aware that 3/2 is a DECIMAL expression that evaluatesDon't be childish.
to 1.5, with precision (15,14) ?
DECLARE I FIXED BINARY INITIAL (3);
DECLARE J FIXED BINARY INITIAL (2);
..I / J...;.
.Fixed-point arithmetic has been a booby trap for language designers from >> the beginning..
Certainly, if you think that 3/2 is a binary expression.
There are booby traps for both binary and decimal fixed-point operations
in almost all languages that allow it, which is, I dare say, a major
reason that only a few languages do that. Let’s see: COBOL (and its ancestors, I suppose), PL/I, Ada, RPG, IBM mainframe C... that’s all I
can think of. I suppose there are some automation languages—that field
is unknown to me. (RPG, of course, avoids the problem by having only single-step statements—no intermediates, no intermediate precisions.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 251 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 23:17:17 |
| Calls: | 5,544 |
| Calls today: | 3 |
| Files: | 11,676 |
| Messages: | 5,109,037 |