glen herrmannsfeldt

In that case, I assert that all Fortran "CANS" be aimed at
IBM's VS Fortran.

It is only fair, you get one assertion, I get another.

-- glen

david frank

Afaik, Windows PL/I is the pinnacle of IBM's PL/I development and was
migrated several years back to support IBM's Z/OS platform
so any shortcomings of that compiler means IBM doesnt have syntax that
allows matching Fortran's capability..

Otoh, CVF is no longer the leader in current Fortran development
but it does have implemented some syntax thats new in THE STANDARD
so whats wrong with my using such syntax? ANS: NOT A THING!!

william m. klein

<much snip>


So now *we* know, ... all of D.F. posts are based on
"As far as <D.F.> knows" ...

I think that answers a LOT!
-- Bill Klein
wmklein <at> ix.netcom.com

david frank

re: origins of Z/OS PL/I

Sooo, what existing compiler do you say IBM used to create Z/OS PL/I (the
only IBM platform OS that receives
a annual PL/I update by IBM)

james j. weinkam

DF posted a code fragment which found the difference between the internal
representations of "A" and "a" then went through a loop in which that difference
was added to the internal representation of each character, x, in the string for
which "a"<=x<="z". This works for ascii because the upper and lower case
characters and each contiguous subsequences. It fails for EBCDIC because
between "a" and "z" lie not only the 26 lower case letters but also 14 special
characters which should not be altered but will be should they appear in the
input. This has nothing to do with the language in which the algorithm is
coded. It is a weakness of the algorithm itself.

glen herrmannsfeldt

While this is true, and I agree that such an algorithm is wrong,
there isn't much in that space.

Between 'A' and 'Z', according to a 1989 EBCDIC table, are
syllable hyphen, numeric space, and backslash. None of the
codes for the TN print train, the popular one with lower case
letters. Between 'a' and 'z' only tilde, though 11 characters
from the TN print train.

It may, then, be a long time before such a mistake is discovered
in production code. Considering the hardware TR (translate)
instruction there isn't much reason to do it any other way.

-- glen

tom linden

Normally don't comment on threads initiated by the OP, but you can

uc_table = translate( collate(),
'ABCDEFGHIJKLMNOPQRSTUVWXYZ',
'abcdefghijklmnopqrstuvwxyz');
key_name = translate(key_name,uc_table, collate());
This will oviously only work if the compiler supports the COLLATE bif.
If not, declare a STATIC array of 256 chars and use in place of the bif.

glen herrmannsfeldt

Others have explained the problems of character conversions,
but the bigger problem is returning strings of unknown size.

It will take some time to understand all the ways that languages
can use to allow returning arguments where the size isn't known
at compile time, and I believe that the answer is different
for different versions of the Fortran standard.

In C, to return a character string it must either be statically
allocated (inconvenient in many cases) or the caller must free()
it (also inconvenient). C makes ******** what other languages
have to do implicitly, that is, allocate and deallocate the
return value at the appropriate time.

PL/I has had varying length character strings from the beginning,
but the maximum length has to be known when they are allocated,
but when is it allocated?

Language designers tend to make the required subroutine calling
sequence relatively simple to allow for a variety of implementations.
Many systems require that, for return values that don't fit in
a register, that the caller supply the space for the return value.
In that case, it needs to be known at compile time, or at least
at call time.

It might be, then, that PL/I requires the maximum length to be
supplied at compile time, but with VARYING length strings the
return value can be any length up to the specified maximum.

Fortran 77 CHARACTER variables, somewhat like the way characters
were done in earlier Fortrans, have a fixed length and are blank
padded. Dummy arguments as far as I can tell have to have a length
specified at compile time. Sometime later the (*) length for
dummy arguments was added.

As far as I can tell, in F2003 a function can be declared with (*)
length, but it must be called from a routine where it is declared
with a non-(*) length.

In any case, a PL/I function can return a VARYING length string
where the length is the length of the RETURN expression. That
length will be used in any expression that uses the return value,
or it can be assigned to a VARYING variable. It might
be that the maximum length needs to be a compile time constant.

-- glen

gib bogle

Heh heh.

richard e maine

No, it was not "sometime later". The (*) length for dummy character
variables is in f77.


That also is an f77 feature, not specifically an f2003 one. If fact, it
is an obsolescent feature in f95 and f2003, so I'd say it was a bit
backwards to describe it as an f2003 feature. It is a full unqualified
part of f77, but is in f95/f2003 with a qualification of being
obsolescent.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain