Fortran - Re: PL/I Cant create a Upper case function

Author

Re: PL/I Cant create a Upper case function

robin

2005-09-11, 6:57 pm

David Frank wrote in message ...
|
|"smokesingdance" <smokesingdance@aol.com> wrote in message
|news:1126431121.016473.321670@g47g2000cwa.googlegroups.com...
|> Is it possible in Fortran to compare characters, character strings and
|> character arrays whiloe ignoring case such that the statements
|> ('a'.EQ.'A') and ('strUING'.EQ.'STruInG') are true?
|
|===============================
|However I assert that PL/I syntax cant be used to create a Upper function,

PL/I has an UPPERCASE function, as well as LOWERCASE.

As well, anyone can write one, buy why would you?

David Frank

2005-09-11, 6:57 pm

"robin" <robin_v@bigpond.com> wrote in message
news:HFXUe.30311$FA3.12756@news-server.bigpond.net.au...
> David Frank wrote in message ...
[color=darkred]
> PL/I has an UPPERCASE function, as well as LOWERCASE.
>
> As well, anyone can write one,

Well anyone aint going to write one, are they?

> buy why would you?

To prove your FAQ assertion that PL/I syntax "has more power than Fortran"
of course.

And with your predicted maroonic reply you have taken a commanding lead as
#1 maroon, altho maroon points MUST be awarded to those accepting another of
your crap replies as factual.

Gib Bogle

2005-09-11, 6:57 pm

David Frank wrote:

> And with your predicted maroonic reply you have taken a commanding lead as
> #1 maroon, altho maroon points MUST be awarded to those accepting another of
> your crap replies as factual.

Maroon is a colour, right? So what does it imply to call someone this
colour?

Rich Townsend

2005-09-11, 6:57 pm

Gib Bogle wrote:
> David Frank wrote:
>
>
>
> Maroon is a colour, right? So what does it imply to call someone this
> colour?

ma·roon1 Audio pronunciation of "maroon" ( P ) Pronunciation Key
(m-rn) tr.v. ma·rooned, ma·roon·ing, ma·roons

often Maroon

1. A fugitive Black slave in the West Indies in the 17th and 18th
centuries.
2. A descendant of such a slave.

Hmmm. I feel no more enlightened.

James J. Weinkam

2005-09-11, 6:57 pm

David Frank wrote:
> "robin" <robin_v@bigpond.com> wrote in message
> news:HFXUe.30311$FA3.12756@news-server.bigpond.net.au...
>
>
>
>
>
> Well anyone aint going to write one, are they?
>
>
>
>
> To prove your FAQ assertion that PL/I syntax "has more power than Fortran"
> of course.

As Robin has said, recent versions of PL/I have UPPERCASE and LOWERCASE built in
functions which work correctly irrespective of the character code in use. Your
code will fail in EBCDIC. All version of PL/I have the TRANSLATE built in
function. UPPERCASE and LOWERCASE are just special cases of TRANSLATE which is
also independent of character code.

Although it would be foolish to do so, it would be easy to write code equivalent
to yours using RANK and BYTE. Only a masochist would do so, since the result
would be slower and non portable.
>
> And with your predicted maroonic reply you have taken a commanding lead as
> #1 maroon, altho maroon points MUST be awarded to those accepting another of
> your crap replies as factual.
>
>

Harold Stevens

2005-09-11, 6:57 pm

In <dg25nv$m07$1@scrotar.nss.udel.edu> Rich Townsend:

[Snip...]

> Hmmm. I feel no more enlightened.

Search for "maroon" on this page of classic Bugs Bunny sound clips:

http://www.earthstation1.com/Bugs_Bunny.html

(It's become Usenet shorthand for a cartoony netkook archetype)

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.

Gib Bogle

2005-09-12, 3:56 am

Harold Stevens wrote:

> In <dg25nv$m07$1@scrotar.nss.udel.edu> Rich Townsend:
>
> [Snip...]
>
>
>
>
> Search for "maroon" on this page of classic Bugs Bunny sound clips:
>
> http://www.earthstation1.com/Bugs_Bunny.html
>
> (It's become Usenet shorthand for a cartoony netkook archetype)
>

Thanks! I learned something today.

Les

2005-09-12, 3:56 am

"Harold Stevens" <wookie@aces.localdomain> wrote in message
news:slrndi99ro.p3m.wyrd@aces.localdomain...
> In <dg25nv$m07$1@scrotar.nss.udel.edu> Rich Townsend:
>
> [Snip...]
>
>
> Search for "maroon" on this page of classic Bugs Bunny sound clips:
>
> http://www.earthstation1.com/Bugs_Bunny.html
>
> (It's become Usenet shorthand for a cartoony netkook archetype)
>

It also means to be abandoned or left isolated as in :

A van carrying red paint, collided with another van carrying blue paint and
several motorists were left marooned.

:-)

Les

David Frank

2005-09-12, 7:59 am

"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
news:W%0Ve.269044$on1.102625@clgrps13...
>
> As Robin has said, recent versions of PL/I have UPPERCASE and LOWERCASE
> built in functions which work correctly irrespective of the character code
> in use. Your code will fail in EBCDIC. All version of PL/I have the
> TRANSLATE built in function. UPPERCASE and LOWERCASE are just special
> cases of TRANSLATE which is also independent of character code.
>
> Although it would be foolish to do so, it would be easy to write code
> equivalent to yours using RANK and BYTE. Only a masochist would do so,
> since the result would be slower and non portable.

As a IBM rep has said, ALL their current compilers support ONLY ASCII as the
native text,
which is what Fortran supports.
Furthermore, like always my challenge only addresses Windows PL/I
capabilities.

I believe you got involved when a similar challenge was for a PL/I TRIM
function to be written, yes/no?
(only Windows PL/I has such a function?)..

A PL/I function declaration cant declare a string output length determined
dynamically by input string length,
in fact mainframe PL/I hardly supports at all, isnt that true?

function User_String_Function(s1) result (s2)
character(*) :: s1
character(len(s1)) :: s2 ! <- cant do this even in Windows PL/I

re: PL/I TRANSLATE

I will have a look at adding a TRANSLATE function to my strings module to
support code conversion
(the 0:255 problem)

note: it was Robin Vowels who again cross-posted a PL/I topic to
comp.lang.fortran

David Frank

2005-09-12, 7:59 am

"Gib Bogle" <bogle@ihug.too.much.spam.co.nz> wrote in message
news:dg23q2$e52$1@lust.ihug.co.nz...
> David Frank wrote:
>
>
> Maroon is a colour, right? So what does it imply to call someone this
> colour?

I replied in comp.lang.pl1 that it meant that the hard-core bakers-dozen of
IBM syncophants still posting has had their pristine IBM-BLUE TEAM PL/I
t-shirts discolored in the last decade by the CRAP they spread in the
newsgroup.

But one of the replies provided a better definition, which is: IBM has
"marooned" PL/I programmers with cutbacks in
platforms supported vs. that supported by their C++ Fortran compilers thus
I have adopted that definition,
marooneds shortens to MAROONS
Does it also question their IQ levels, well who would hire one of them
today?

Meanwhile IBM moves on with a Fortran (claiming some F2003 capabilities) for
Linux
But has NO plans for a PL/I for Linux, and has stopped its PL/I quarterly
newsletter 5 years ago.

William M. Klein

2005-09-12, 6:58 pm

If your concern (as if you actually had one) was for IBM providing the UPPERCASE
and LOWERCASE "BIF's" for Windows PL/I, then please see:
http://publibfi.boulder.ibm.com/epubs/pdf/ibm3lr20.pdf

which is the Language Refererence (for among others) for:

WSED PL/I for Windows

Then look at page 440 for LOWERCASE
and
Page 495 for UPPERCASE

I believe (but won't swear to it) that there actuallyhas been one or more
releases after this one, but this just shows that these built-in functions have
been available for Windows PL/I (from IBM) since 2003 (the copyright for that
manual)

Of course, it is interesting that you "CAN'T" challenges now ONLY apply to PL/I
for Windows (from IBM). You really do need to make that clearer in the future.

As far as EBCDIC goes, you may want to check out:
http://www-1.ibm.com/support/docvie...g27005323&aid=1

and start reading at page 35 where it says (in part),

The workstation compilers support options that instruct the operating system to
treat data and floating-point operations the same way that the mainframe does.
There are suboptions of the DEFAULT compile-time option that you should specify
for all mainframe applications that might need to be changed when moving code to
the workstation:
DEFAULT(EBCDIC) instead of ASCII
DEFAULT(HEXADEC) instead of IEEE
DEFAULT(E(HEXADEC)) instead of DFT(E(IEEE))
DEFAULT (NONNATIVE) instead of NATIVE
DEFAULT (NONNATIVEADDR) instead of NATIVEADDR
For more information on these compile-time options, see "DEFAULT" on page 46."

--
Bill Klein
wmklein <at> ix.netcom.com
"David Frank" <dave_frank@hotmail.com> wrote in message
news:X9cVe.10646$_84.9720@newsread1.news.atl.earthlink.net...
>
> "James J. Weinkam" <jjw@cs.sfu.ca> wrote in message
> news:W%0Ve.269044$on1.102625@clgrps13...
>
> As a IBM rep has said, ALL their current compilers support ONLY ASCII as the
> native text,
> which is what Fortran supports.
> Furthermore, like always my challenge only addresses Windows PL/I
> capabilities.
>
> I believe you got involved when a similar challenge was for a PL/I TRIM
> function to be written, yes/no?
> (only Windows PL/I has such a function?)..
>
> A PL/I function declaration cant declare a string output length determined
> dynamically by input string length,
> in fact mainframe PL/I hardly supports at all, isnt that true?
>
> function User_String_Function(s1) result (s2)
> character(*) :: s1
> character(len(s1)) :: s2 ! <- cant do this even in Windows PL/I
>
> re: PL/I TRANSLATE
>
> I will have a look at adding a TRANSLATE function to my strings module to
> support code conversion
> (the 0:255 problem)
>
> note: it was Robin Vowels who again cross-posted a PL/I topic to
> comp.lang.fortran
>
>
>
>
>

Tim Challenger

2005-09-12, 6:58 pm

On Mon, 12 Sep 2005 09:48:39 GMT, David Frank wrote:

> As a IBM rep has said, ALL their current compilers support ONLY ASCII as the
> native text,

How do they ever manage across the road on the mainframe, I wonder?
--
Tim C.

Dick Hendrickson

2005-09-12, 6:58 pm

James J. Weinkam wrote:
> David Frank wrote:
>
>
>
> As Robin has said, recent versions of PL/I have UPPERCASE and LOWERCASE
> built in functions which work correctly irrespective of the character
> code in use. Your code will fail in EBCDIC. All version of PL/I have
> the TRANSLATE built in function. UPPERCASE and LOWERCASE are just
> special cases of TRANSLATE which is also independent of character code.
>
> Although it would be foolish to do so, it would be easy to write code
> equivalent to yours using RANK and BYTE. Only a masochist would do so,
> since the result would be slower and non portable.
>
I'm curious about the non portable part. It's easy to write
a standard conforming portable Fortran uppercase or
lowercase function. Is the PL/I version non portable
because you'd attempt to mimic Dave's Fortran coding style,
or is there an inherent reason why character conversions
are nonportable. I haven't seen Dave's Fortran functions
(at least not in this round ;) ). But, he often writes
functions that are special cased to one particular compiler
rather than use the natural Fortran character operations.
Like I said, I'm curious if that's what makes the PL/I
version non portable.

Dick Hendrickson

David Frank

2005-09-12, 6:58 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:vugVe.3671$s35.1670@fe09.news.easynews.com...
>
> Of course, it is interesting that you "CAN'T" challenges now ONLY apply to
> PL/I for Windows (from IBM). You really do need to make that clearer in
> the future.
>

http://home.earthlink.net/~dave_gemini/pli_cant.faq

has always asserted its "CANTS" are aimed at IBM's Windows PL/I

glen herrmannsfeldt

2005-09-12, 6:58 pm

David Frank wrote:

> http://home.earthlink.net/~dave_gemini/pli_cant.faq

> has always asserted its "CANTS" are aimed at IBM's Windows PL/I

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

2005-09-12, 6:58 pm

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:ZrCdnW9D84VxMLjeRVn-qA@comcast.com...
> David Frank wrote:
>
>
>
>
> 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
>

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

2005-09-12, 6:58 pm

"David Frank" <dave_frank@hotmail.com> wrote in message
news:moiVe.10799$_84.3429@newsread1.news.atl.earthlink.net...
>
<much snip>

> Afaik,

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

2005-09-12, 6:58 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:gEiVe.35341$j34.22673@fe07.news.easynews.com...
>

> "As far as <D.F.> knows" ...
>
> I think that answers a LOT!
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>

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

2005-09-12, 6:58 pm

Dick Hendrickson wrote:
>
>
> James J. Weinkam wrote:
>
> I'm curious about the non portable part. It's easy to write
> a standard conforming portable Fortran uppercase or
> lowercase function. Is the PL/I version non portable
> because you'd attempt to mimic Dave's Fortran coding style,
> or is there an inherent reason why character conversions
> are nonportable. I haven't seen Dave's Fortran functions
> (at least not in this round ;) ). But, he often writes
> functions that are special cased to one particular compiler
> rather than use the natural Fortran character operations.
> Like I said, I'm curious if that's what makes the PL/I
> version non portable.
>
> Dick Hendrickson
>
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

2005-09-12, 6:58 pm

James J. Weinkam wrote:

(snip)

> 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.

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

2005-09-12, 6:58 pm

On Mon, 12 Sep 2005 11:54:08 -0700, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

> James J. Weinkam wrote:
>
> (snip)
>
>
> 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
>
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

2005-09-12, 6:58 pm

Dick Hendrickson wrote:

(snip)

> I'm curious about the non portable part. It's easy to write
> a standard conforming portable Fortran uppercase or
> lowercase function. Is the PL/I version non portable
> because you'd attempt to mimic Dave's Fortran coding style,
> or is there an inherent reason why character conversions
> are nonportable.

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 explicit 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

2005-09-12, 6:58 pm

Les wrote:

> "Harold Stevens" <wookie@aces.localdomain> wrote in message
> news:slrndi99ro.p3m.wyrd@aces.localdomain...
>
>
>
> It also means to be abandoned or left isolated as in :
>
> A van carrying red paint, collided with another van carrying blue paint and
> several motorists were left marooned.
>
> :-)

Heh heh.

Richard E Maine

2005-09-12, 6:58 pm

In article <AYmdnb_3qIfDe7jeRVn-tg@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> 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.

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

> 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.

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

glen herrmannsfeldt

2005-09-12, 6:58 pm

Richard E Maine wrote:

> In article <AYmdnb_3qIfDe7jeRVn-tg@comcast.com>,
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

[color=darkred]
> No, it was not "sometime later". The (*) length for dummy character
> variables is in f77.

OK, I found it now. It is not at all described in 15.9.3 describing
the association of dummy and actual arguments, or at least I don't see
it there.

[color=darkred]
> 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.

Yes, I found it near the (*) dummy argument description in 8.4.2.

So then the question still is how to have a function that returns
a string with a length related to the length of its arguments, or
even not related to the length of the arguments.

As far as I understand 8.4.2, each calling program can have only one
length for the return value, though different calling programs can
have different lengths.

Please not that I am not at all interested in a language feature
bragging game, but only serious discussion of language features,
and their usefulness or lack thereof.

-- glen

James J. Weinkam

2005-09-12, 6:58 pm

glen herrmannsfeldt wrote:
> James J. Weinkam wrote:
>
> (snip)
>
>
>
> 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
>
And those are the most insidious errors, because they always seem to manifest
themselves at the most awkward possible moment, years after anyone has any idea
what the source of the problem might be.

glen herrmannsfeldt

2005-09-12, 9:56 pm

James J. Weinkam wrote:

> glen herrmannsfeldt wrote:

(snip)

[color=darkred]
[color=darkred]
> And those are the most insidious errors, because they always seem to
> manifest themselves at the most awkward possible moment, years after
> anyone has any idea what the source of the problem might be.

Yes. Though one I have wondered about more, the supposed advantage of
little endian byte order in calling subroutines by reference, that one
can pass a larger integer to a smaller dummy argument. I consider it a
di

vantage in that it hides the size mismatch until larger data
values are used, possibly many years later.

-- glen

Richard Maine

2005-09-12, 9:56 pm

I'm posting this followup only to clf. (I probably should have done that
on my earlier one, but I wasn't paying adequate attention to the
newsgroups line).

In article <PbadneNQz-BDbbjeRVn-uQ@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> So then the question still is how to have a function that returns
> a string with a length related to the length of its arguments, or
> even not related to the length of the arguments.

That's been discussed here several times before. The short summary is:

f77- pretty much not possible, and that's by intentional design. Though
I wasn't involved in f77, it is pretty evident from reading the result
that someone went through looking for anything that might even hint at
needing dynamic memory allocation in even the most naive of
implementations, and added a restriction prohibiting that. One or two of
the restrictions just don't make any sense unless you view them from a
viewpoint like that.

f2003 - relatively "clean" using an allocatable function result.

f90/f95 - possible in many cases, at least if you are a sufficient
wizard in specification expressions (as exemplified by our resident
specification expression and TRANSFER intrinsic wizard, James Van
Buskirk). F95 opened the door to less adept wizards, who mostly just
need to remember that PURE functions are allowed in f95, so you can
embed it all in such a function, though that is awfully "wordy" and
might end up with essentially needing to do everything twice.

glen herrmannsfeldt

2005-09-12, 9:57 pm

Richard Maine wrote:

(I wrote)

[color=darkred]
> That's been discussed here several times before. The short summary is:

I thought so, too, but maybe not quite finished.

> f77- pretty much not possible, and that's by intentional design. Though
> I wasn't involved in f77, it is pretty evident from reading the result
> that someone went through looking for anything that might even hint at
> needing dynamic memory allocation in even the most naive of
> implementations, and added a restriction prohibiting that. One or two of
> the restrictions just don't make any sense unless you view them from a
> viewpoint like that.

That sounds about right.

> f2003 - relatively "clean" using an allocatable function result.

I found in 6.3.3.1 that ALLOCATABLEs aren't deallocated on return
if they are function result variables. Also in 6.3.3.1 is that
allocatable variables as return values are deallocated.

In C pretty much no-one wants to return dynamically allocated
variables from functions. The caller would then be expected to
free() them, but that only works if it is assigned to a variable,
and it is easy to forget. Most functions that need to return a
string result take a previously allocate argument and length.
(The rest return a pointer to a static variable.)

I am not yet sure whether PL/I allows a CONTROLLED function
return value, but it would have the same problem as C.
There is no automatic ALLOCATE or FREE in PL/I; the idea is that
the user has complete control over the variable. Sort of like
Fortran SAVEd ALLOCATABLE, except that they stack if you allocate
one that is already allocated. FREEing an unallocated variable
is legal, and does nothing.

> f90/f95 - possible in many cases, at least if you are a sufficient
> wizard in specification expressions (as exemplified by our resident
> specification expression and TRANSFER intrinsic wizard, James Van
> Buskirk). F95 opened the door to less adept wizards, who mostly just
> need to remember that PURE functions are allowed in f95, so you can
> embed it all in such a function, though that is awfully "wordy" and
> might end up with essentially needing to do everything twice.

OK, that is enough for me.

-- glen

Greg Lindahl

2005-09-13, 3:57 am

In article <nospam-399321.17523312092005@news.supernews.com>,
Richard Maine <nospam@see.signature> wrote:

>I'm posting this followup only to clf. (I probably should have done that
>on my earlier one, but I wasn't paying adequate attention to the
>newsgroups line).

The minus of this is that those of us killing all crossposts to
comp.lang.pl1 get to see this message -- the rest of the thread is
100% killed.

-- greg

Richard Maine

2005-09-13, 3:57 am

In article <ybWdnXJwk-RLs7veRVn-qQ@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> I found in 6.3.3.1 that ALLOCATABLEs aren't deallocated on return
> if they are function result variables.

Of course not. That would make allocatable functions useless if the
function always deallocated its result before returning it. But the
result does get deallocated later - *AFTER* it is used in the expression
that the function is referenced in; the difference in time matters.

As I have said many times here, there is *NO* way for a user to cause a
memory leak using allocatables. (Um, well, in f95 and after - f90
allocatables were badly messed up this area). If you find one, then it
is a bug in the standard. But you haven't found one. I don't have time
at the moment to find the right citation, but I'm confident of this one
- it is an "obvious" issue for allocatable function results, and one
that I recall being addressed.

Walter Spector

2005-09-13, 3:57 am

glen herrmannsfeldt wrote:
> ...
>
> I found in 6.3.3.1 that ALLOCATABLEs aren't deallocated on return
> if they are function result variables. Also in 6.3.3.1 is that
> allocatable variables as return values are deallocated.

Yes. Glen, perhaps the thing you are missing WRT Fortran is that
the interfaces must be 'explicit' between the caller and callee for
these things to work right. (Via using contained procedures, or,
less desireably, by writing INTERFACE blocks.) The caller side then
has knowlege of the fact that the callee will be returning a dynamically
sized object. It can then deallocate the space accordingly. No need
for fancy garbage collection support.

Walt
-...-
Walt Spector
(w6ws att earthlinkk dott nett)

Mark Yudkin

2005-09-13, 3:57 am

"David Frank" <dave_frank@hotmail.com> wrote in message
news:X9cVe.10646$_84.9720@newsread1.news.atl.earthlink.net...
> As a IBM rep has said, ALL their current compilers support ONLY ASCII as
> the native text,

Either you're talking crap, or you're talking crap. Either way, IBM has a
range of compilers supporting Unicode, including PL/I (where the data type
is spelled "wchar", as it is in C).

> which is what Fortran supports.
That translates to "Fortran Can[']t c[/C]reate a[n] Upper c[/C]ase
f[/F]unction", to state it without the 5 English errors (aka "XXXXwit Frank
Can't Write English").

BTW, your posted UPPER fails in German and many other languages. As such, it
is useless. Suggest you visit http://www.w3.org/International/ and learn the
basics of linguistic computing.

Mark Yudkin

2005-09-13, 3:57 am

His code fails to handle accented characters such as German's aöü => ÄÖÜ,
Spanish ñ => Ñ, etc. As such, his code is totally useless outside of his
tunnel vision view of the tiny part of the world he lives in (if that).

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:acadnee9bug1U7jeRVn-pg@comcast.com...
> James J. Weinkam wrote:
>
> (snip)
>
>
> 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
>

glen herrmannsfeldt

2005-09-13, 3:57 am

Richard Maine wrote:

(I wrote)

[color=darkred]
> Of course not. That would make allocatable functions useless if the
> function always deallocated its result before returning it. But the
> result does get deallocated later - *AFTER* it is used in the expression
> that the function is referenced in; the difference in time matters.

I was just commenting out loud on having found the right
part of the standard, or what I believed was right.

Note that in C it isn't an unusual mistake to return a pointer
to an automatic variable, which then disappears as soon as you
return leaving a pointer to nowhere. It would seem easy to warn
about, but I don't know that many compilers do it.

> As I have said many times here, there is *NO* way for a user to cause a
> memory leak using allocatables. (Um, well, in f95 and after - f90
> allocatables were badly messed up this area). If you find one, then it
> is a bug in the standard. But you haven't found one. I don't have time
> at the moment to find the right citation, but I'm confident of this one
> - it is an "obvious" issue for allocatable function results, and one
> that I recall being addressed.

No leaks, and no accidental deallocation at just the wrong time
isn't easy to get right.

With C it is easy to create a memory leak. PL/I won't leak, as you
can always get the memory back again, but you can still make
mistakes with it.

thanks,

-- glen

David Frank

2005-09-13, 3:57 am

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:PbadneNQz-BDbbjeRVn-uQ@comcast.com...
>
> So then the question still is how to have a function that returns
> a string with a length related to the length of its arguments, or
> even not related to the length of the arguments.
>
> As far as I understand 8.4.2, each calling program can have only one
> length for the return value, though different calling programs can
> have different lengths.
>

Below shud produce following results when Fortran compilers compliant with
THE STANDARD are available.
(using my Upper/Lower functions in)
http://home.earthlink.net/~dave_gemini/strings.f90

character(:),allocatable :: string

string = Upper('the quick brown')
write (*,*) len(string),string ! outputs: 15 THE QUICK BROWN

string = Lower(string//' FOX')
write (*,*) len(string), string ! outputs: 19 the quick brown fox

OK, forget that Windows PL/I has a Upper case function and other PL/I
compilers dont, (except for Z/OS a clone),
back to current topic.

Show us a PL/I program equivalent of below F90 syntax since you are
"seriously interested in language features"

Note: there are NO exec declarations to receive a fixed length string.

! ------------------
program test
write (*,*) '|', Pass_Thru('the quick brown'), '|' ! outputs: |the
quick brown|
stop

contains
function Pass_Thru(s1) result(s2)
character(*) :: s1
character(len(s1)) :: s2
s2 = s1
end function
end program

David Frank

2005-09-13, 6:59 pm

"David Frank" <dave_frank@hotmail.com> wrote in message
news:X9cVe.10646$_84.9720@newsread1.news.atl.earthlink.net...
>
> I will have a look at adding a TRANSLATE function to my strings module to
> support code conversion

http://home.earthlink.net/~dave_gemini/strings.f90

has been uploaded with following NEW addition to its repetoire of string
functions..

! ---------------------------------
FUNCTION Translate(s1,incode,outcode) RESULT (s2)
CHARACTER(*) :: s1, incode, outcode
CHARACTER(LEN(s1)) :: s2
CHARACTER :: ch
INTEGER :: i, j

DO i = 1,LEN(s1)
ch = s1(i:i)
j = index(incode,ch) ; IF (j > 0) ch = outcode(j:j)
s2(i:i) = ch
END DO
END FUNCTION Translate

David Frank

2005-09-13, 6:59 pm

I "improved" my translate function to combine the incode, outcode into a
codes(2) array input.
e.g. write (*,*) Translate ('abc', ['abc','ABC'] ) outputs ABC

! ---------------------------------
FUNCTION Translate(s1,codes) RESULT (s2)
CHARACTER(*) :: s1, codes(2)
CHARACTER(LEN(s1)) :: s2
CHARACTER :: ch
INTEGER :: i, j

DO i = 1,LEN(s1)
ch = s1(i:i)
j = index(codes(1),ch) ; IF (j > 0) ch = codes(2)(j:j)
s2(i:i) = ch
END DO
END FUNCTION Translate

>
>

Dick Hendrickson

2005-09-14, 7:00 pm

David Frank wrote:
> "David Frank" <dave_frank@hotmail.com> wrote in message
> news:X9cVe.10646$_84.9720@newsread1.news.atl.earthlink.net...
>
>
>
> http://home.earthlink.net/~dave_gemini/strings.f90
>
> has been uploaded with following NEW addition to its repetoire of string
> functions..
>
> ! ---------------------------------
> FUNCTION Translate(s1,incode,outcode) RESULT (s2)
> CHARACTER(*) :: s1, incode, outcode
> CHARACTER(LEN(s1)) :: s2
> CHARACTER :: ch
> INTEGER :: i, j
>
> DO i = 1,LEN(s1)
> ch = s1(i:i)
> j = index(incode,ch) ; IF (j > 0) ch = outcode(j:j)
> s2(i:i) = ch
> END DO
> END FUNCTION Translate
>
Maybe I need another cup of coffee, but I'm just not
seeing something. How do you declare this function in the
calling routine?

Dick Hendrickson

David Frank

2005-09-14, 7:00 pm

"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:M3YVe.246092$5N3.208142@bgtnsc05-news.ops.worldnet.att.net...
>
>
> David Frank wrote:
> Maybe I need another cup of coffee, but I'm just not
> seeing something. How do you declare this function in the
> calling routine?
>
> Dick Hendrickson
>

Is below what you are asking?
http://home.earthlink.net/~dave_gemini/strings.f90

include 'strings.f90'
! -------------------
program dick_test
use string_functions

write (*,*) Translate('abc',['abc','ABC'] ) ! outputs ABC
end program

Dick Hendrickson

2005-09-14, 7:00 pm

David Frank wrote:
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> news:M3YVe.246092$5N3.208142@bgtnsc05-news.ops.worldnet.att.net...
>
>
>
> Is below what you are asking?
> http://home.earthlink.net/~dave_gemini/strings.f90
>
> include 'strings.f90'
> ! -------------------
> program dick_test
> use string_functions
>
> write (*,*) Translate('abc',['abc','ABC'] ) ! outputs ABC
> end program
>
>
Yes, exactly. I had forgotten that having a length that
isn't a compile time constant requires an explicit interface.

thanks

Dick Hendrickson

John Harper

2005-09-14, 7:00 pm

In article <wmZVe.11590$9i4.4720@newsread2.news.atl.earthlink.net>,
David Frank <dave_frank@hotmail.com> wrote:
....[color=darkred]
>program dick_test
>use string_functions
>
>write (*,*) Translate('abc',['abc','ABC'] ) ! outputs ABC
>end program

Eh? The dummy arguments of Translate are three scalars but there are
two actual arguments, a scalar and an array of size 2. That won't
compile, but it's OK if that write statement is replaced by
write (*,*) Translate('abc', 'abc', 'ABC' )
While we're at it, I'd recommend a graceful error exit if
len(incode)/=len(outcode). INTENT(IN) would also allow Translate to
be a pure or elemental function, which would help some users, but it
would annoy those who'd want the error exit to do something forbidden
in a pure procedure. The following compiles and runs, for example:

MODULE string_functions
CONTAINS
ELEMENTAL FUNCTION Translate(s1,incode,outcode) RESULT (s2)
CHARACTER(*),INTENT(IN) :: s1,incode,outcode
CHARACTER(LEN(s1)) :: s2
CHARACTER :: ch
INTEGER :: i, j
IF (len(incode)/=len(outcode)) THEN
s2 = ''
ELSE
DO i = 1,LEN(s1)
ch = s1(i:i)
j = index(incode,ch) ; IF (j > 0) ch = outcode(j:j)
s2(i:i) = ch
END DO
END IF
END FUNCTION Translate
END MODULE string_functions

PROGRAM dick_test
USE string_functions

PRINT *, Translate('?yx','abc',& ! outputs a blank line
'ABCDEFGHIJKLMNOPQRSTUVWXYZ')
PRINT *, Translate('?yx','abcdefghijklmnopqrstuvwxyz',&
'ABCDEFGHIJKLMNOPQRSTUVWXYZ') ! outputs ?YX
END PROGRAM dick_test

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

David Frank

2005-09-14, 7:00 pm

"John Harper" <harper@mcs.vuw.ac.nz> wrote in message
news:1126736231.685529@bats.mcs.vuw.ac.nz...
>
> Eh? The dummy arguments of Translate are three scalars but there are
> two actual arguments, a scalar and an array of size 2. That won't
> compile, but it's OK if that write statement is replaced by
> write (*,*) Translate('abc', 'abc', 'ABC' )
> While we're at it, I'd recommend a graceful error exit if
> len(incode)/=len(outcode).

Guaranteed same length, so not necessary, (see below)

Yesterday, I "improved" my translate function to combine the incode,
outcode into a
codes(2) array input.
Neither you nor Dick Hendrickson seem to have noted that posted
"improvement" prior to posting your replies..
Thanks for your other observations..

! ---------------------------------
FUNCTION Translate(s1,codes) RESULT (s2)
CHARACTER(*) :: s1, codes(2)
CHARACTER(LEN(s1)) :: s2
CHARACTER :: ch
INTEGER :: i, j

DO i = 1,LEN(s1)
ch = s1(i:i)
j = index(codes(1),ch) ; IF (j > 0) ch = codes(2)(j:j)
s2(i:i) = ch
END DO
END FUNCTION Translate

Dave Thompson

2005-09-23, 3:58 am

On Tue, 13 Sep 2005 07:50:35 +0200, "Mark Yudkin"
<myudkinATcompuserveDOTcom@boingboing.org> wrote:

> "David Frank" <dave_frank@hotmail.com> wrote in message
> news:X9cVe.10646$_84.9720@newsread1.news.atl.earthlink.net...
>
> Either you're talking crap, or you're talking crap. Either way, IBM has a
> range of compilers supporting Unicode, including PL/I (where the data type
> is spelled "wchar", as it is in C).
>
Actually it's wchar_t. In C it's an optional typedef, thus an alias
for another integer type typically long; in C++ it's a keyword, hence
reserved, and distinguishable for overloading. (But still an integer
type; in C and C++ both character types are just various sizes of
integer, and character codes are just integers; and C strings are just
array of char, while C++ std::[w]string are count + usually sepearate
possibly shared data.)

And wchar_t isn't required in either standard to be Unicode, just a
character set distinct from and at least as large as regular 'narrow'
char; it is (clearly) designed and intended to _allow_ Unicode, but
that isn't required. In C99, there is a macro by which the compiler
(or more precisely preprocessor) can indicate _if_ wchar is 10646, and
which version, and thus a program can conditionally rely on it.

- David.Thompson1 at worldnet.att.net

Dave Thompson

2005-09-23, 3:58 am

On Mon, 12 Sep 2005 23:54:10 -0700, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

> Richard Maine wrote:
<snip>
>
> No leaks, and no accidental deallocation at just the wrong time
> isn't easy to get right.
>
> With C it is easy to create a memory leak. PL/I won't leak, as you
> can always get the memory back again, but you can still make
> mistakes with it.
>
To be clear: PL/I _CONTROLLED_ like F90-fixed-95-or-03 ALLOCATABLE
won't leak. PL/I also has "raw" pointer ALLOCATE and DEALLOCATE which
are just as powerful and dangerous as C malloc+/free, and F90 has them
equally unsafe for dangling/stale though not for wrong-type.

Although, as discussed upthread, PL/I and F>=77 have char string
handling including function return builtin to the language, largely
eliminating the most common _need_ for allocation in C.

- David.Thompson1 at worldnet.att.net

glen herrmannsfeldt

2005-09-23, 7:58 am

Dave Thompson wrote:

(snip)

> To be clear: PL/I _CONTROLLED_ like F90-fixed-95-or-03 ALLOCATABLE
> won't leak. PL/I also has "raw" pointer ALLOCATE and DEALLOCATE which
> are just as powerful and dangerous as C malloc+/free, and F90 has them
> equally unsafe for dangling/stale though not for wrong-type.

Just because it won't leak doesn't mean it can't be done wrong.

A program I was working with some years ago would crash running
out of memory at around 3GB, so I claimed a memory leak. The
input and output files were much smaller than that. When
run with purify no leak was found.

It seems that the program was multithreaded, one thread reading
and processing the input, another processing the intermediate
values and writing them out. If the input thread was faster
than the output thread large amounts of allocated memory would
build up until it died.

Eventually enough of it was rewritten that the problem went
away, though I never heard what was actually done.
Still, it didn't leak...

-- glen

Sponsored Links