PL/I Newsletter 
Author Message
 PL/I Newsletter

The current issue of the PL/I Newsletter is at

http://www.*-*-*.com/



Thu, 27 May 2004 07:45:17 GMT  
 PL/I Newsletter
Just some comments on the new VA BIFs section of this newsletter:

The suggested means of serially iterating over ordinals is unnecessarily
verbose, and accordingly unnecessarily confusing. The UPTHRU construct, as
per the documentation for the types 2 and 3 DO, is much easier to read.

COMPARE is defined to be a byte-by-byte storage comparison, not a character
comparison. It's part of a set of routines: PLIFILL, PLIMOVE, PLIOVER being
the others, that support the equivalent mem* functions of C. There's also
HEXIMAGE which has no direct C equivalent.

CURRENTSIZE is not new, only the spelling is. It used to be spelled
CURRENTSTORAGE.

According to the LRM, PRED raises OVERFLOW, not UNDERFLOW when there is no
such number; I haven't tested who's correct though.

You mentioned FILEOPEN, presumably the FILEDD* BIFs will be in the next
newsletter...


Quote:
> The current issue of the PL/I Newsletter is at

> http://www.users.bigpond.com/robin_v/pli-n4.htm



Thu, 27 May 2004 20:57:55 GMT  
 PL/I Newsletter

Date: Sun, 9 Dec 2001 13:57:55 +0100

Quote:
> Just some comments on the new VA BIFs section of this newsletter:
> The suggested means of serially iterating over ordinals is unnecessarily
> verbose, and accordingly unnecessarily confusing. The UPTHRU construct, as
> per the documentation for the types 2 and 3 DO, is much easier to read.

The suggested method happens to follow the style given as the
*primary* example in the LRM.
        The suggested method is independent of any additions or removals
to the members of the list, and is therefore general.
The UPTHRU/DOWNTO method may be appropriate where the members are fixed.
        Just because only four members were used in the example,
there's nothing to stop other directions from being added, such
as north_east, etc, in which case the UPTHRU method may not
be appropriate.
        The suggested method opens the way to treat every second
member, for example, by using REPEAT (ORDINALSUCC(ORDIALSUCC(Direction))),
which would be appropriate to cycle thru N, E, S, W, or NE, SE, SW, and NW
when the set consists of the 8 points of the compass.
        For a run thru a subset of the values, however, the UPTHRU method
may be better.

Quote:
> COMPARE is defined to be a byte-by-byte storage comparison, not a character
> comparison. It's part of a set of routines: PLIFILL, PLIMOVE, PLIOVER being
> the others, that support the equivalent mem* functions of C. There's also
> HEXIMAGE which has no direct C equivalent.

CHARACTER compares are always conducted on a byte-by-byte basis.
<character> is synonymous with <byte>.
I've changed the word <character> to <byte>.

Quote:
> CURRENTSIZE is not new, only the spelling is.

According to the manual, the whole thing is new.

Quote:
> It used to be spelled CURRENTSTORAGE.

Well, then, it's new.

Quote:
> According to the LRM, PRED raises OVERFLOW, not UNDERFLOW when there is no
> such number; I haven't tested who's correct though.

The manual is wrong.
        If you look at SUCC, the same thing is said to occur.
        When an attempt is made to obtain a FLOAT number that is smaller than
the smallest representabkle number, the UNDERFLOW condition is raised.
        Similarly, when an attempt is made to obtain a number larger than the
largest representable number, the OVERFLOW condtion is raised.
        The implementation in the compiler that I have is erroneous.
The UNDERFLOW condition is not raised, but the value returned is zero.
(this is not standard action; the standard action is to raise the
UNDERFLOW condition and to continue with the value <zero>).
        In the same compiler, in the case of SUCC, the OVERFLOW condition
is not raised; instead the ERROR condition is raised, with an erroneous
message that "X in TRUNC(X) is invalid".
        The correct action is to raise the OVERFLOW condition and then to
raise the ERROR condition.

Quote:
> You mentioned FILEOPEN, presumably the FILEDD* BIFs will be in the next
> newsletter..

.
The article mentioned that the series was to be continued in the next
newsletter.

BTW, contributions are always welcome.



Fri, 28 May 2004 13:50:05 GMT  
 PL/I Newsletter
Subject: Re: PL/I Newsletter
Quote:
> According to the LRM, PRED raises OVERFLOW, not UNDERFLOW when there is no
> such number; I haven't tested who's correct though.

.
Peter Elderon pointed out that the manual is correct.
.
        When PRED(X) attempts to obtain a FLOAT number that is less than
-HUGE(X), the OVERFLOW condtion is raised.
        When SUCC(X) attempts to obtain a FLOAT number that is greater than
HUGE(X), the OVERFLOW condtion is raised.
.
        PRED(TINY(X)) yields 0; SUCC(-TINY(X)) yields 0.  In each case,
the UNDERFLOW condition is not raised.
.
        However, there is an error in the compiler.  In the case of PRED
and SUCC, the OVERFLOW condition is not raised; instead the ERROR condition
is raised, with an erroneous message that "X in TRUNC(X) is invalid".
        The correct default action is to raise the OVERFLOW condition and
then to raise the ERROR condition.  Peter intimates that the error will be
corrected.


Sat, 29 May 2004 09:59:26 GMT  
 PL/I Newsletter
P.S. The descriptions of PRED and SUCC in the Newsletter have been
amended.


Sat, 29 May 2004 10:01:26 GMT  
 PL/I Newsletter

Quote:

Services
> CHARACTER compares are always conducted on a byte-by-byte basis.
> <character> is synonymous with <byte>.
> I've changed the word <character> to <byte>.

Character comparisons in PL/I ignore trailing blanks. For VARZ comparisons,
'00'x is also ignored. Character is also used in PL/I to mean any of CHAR,
GRAPHIC or WCHAR, so one must be careful. The LRM deliberately used byte.

Quote:
> > CURRENTSIZE is not new, only the spelling is.

> According to the manual, the whole thing is new.

> > It used to be spelled CURRENTSTORAGE.

> Well, then, it's new.

??? Other than the spelling, what's new?


Sat, 29 May 2004 15:07:30 GMT  
 PL/I Newsletter


Quote:
><character> is synonymous with <byte>.

A character may be multiple bytes.

--
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to

-----------------------------------------------------------



Sun, 30 May 2004 21:08:56 GMT  
 PL/I Newsletter

Quote:
>Date: Tue, 11 Dec 2001 08:07:30 +0100
>Character comparisons in PL/I ignore trailing blanks.

.
Character comparisons in PL/I do not ignore trailing blanks.
Character comparisons proceed from left to right.  Comparison
terminates only when two non-equal characters are encountered.
If all characters are equal, EVERY character is examined, even
trailing blanks.
        Trailing characters (including blank and non-blank characters)
are only ignored when two characters compare not equal.
.
Quote:
> For VARZ comparisons, '00'x is also ignored.

.
The '00'x character is examined when one of the strings is shorter than
the other and characters thus far are equal.
And when both strings are the same length, and all characters
compare equal, the '00'x bytes are always examined.
.
The '00'x character is the only means to tell when the
end of the string is reached.
.

Quote:
> Character is also used in PL/I to mean any of CHAR,
>GRAPHIC or WCHAR, so one must be careful. The LRM deliberately used byte.

It doesn't.
This is what it says for CHARACTER:
"CHARACTER is a left-to-right, CHARACTER-BY-CHARACTER comparison of
CHARACTERS ... (my emphasis)"
This is what is says for GRAPHIC:
"GRAPHIC is a left-to-right, SYMBOL-BY-SYMBOL comparison of DCBS characters."
.
In ther words, "character" is used to refer to data of type CHARACTER.
When reference is made to other string data, it is to "symbols",
or is qualified, viz, as "GRAPHIC characters" or as "DCBS characters".
Or as "GRAPHIC data", etc etc etc.
.


Mon, 31 May 2004 07:01:54 GMT  
 PL/I Newsletter

Quote:

> ><character> is synonymous with <byte>.

> A character may be multiple bytes.

Only if it's a GRAPHIC etc, in which case it's called
"symbol" or "GRAPHIC character" etc.
Quote:
> --
> -----------------------------------------------------------
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I



Mon, 31 May 2004 07:11:19 GMT  
 PL/I Newsletter

Quote:

> Character comparisons in PL/I do not ignore trailing blanks.
> Character comparisons proceed from left to right.  Comparison
> terminates only when two non-equal characters are encountered.
> If all characters are equal, EVERY character is examined, even
> trailing blanks.
>         Trailing characters (including blank and non-blank characters)
> are only ignored when two characters compare not equal.

If two character strings differ only in the number of trailing blanks (if any) that each of them
has, they compare equal.  Certainly it should cause no confusion to paraphrase this as ignoring
trailing blanks.  What really happens, at least conceptually is that the shorter string is padded
with blanks to match the longer string in length.


Mon, 31 May 2004 07:43:51 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. The PL/I Connection (PL/I Newsletter No. 6)

2. The PL/I Newsletter

3. PL/I Newsletter

4. The PL/I Newsletter (August 2002)

5. Call for PL/I Newsletter articles

6. PL/I Newsletters - URLs for some back numbers (third try)

7. PL/I Newsletters -- URLs for back issues

8. PL/I Newsletters -- URLs for some back issues

9. PL/I Newsletter (June 2001)

10. PL/I Newsletter

11. Request for Articles for PL/I Newsletter

12. PL/I Newsletter

 

 
Powered by phpBB® Forum Software