case insensitive string comparison

[y.bi...@googlemail.com]

Hi all!

I need to compare to strings.
Fortran can do it with '==' but it is case sensitive. Is there any way to make comparison case-insensitive?

Thanks!

[\"Vladimír Fuka <"name.surnameat]

> Is there any way to make comparison case-insensitive?

Just convert it to upper or lower case first?

[y.bi...@googlemail.com]

> Just convert it to upper or lower case first?

Good idea!
is there any build-in function to convert case?

[Arjen Markus]

On Monday, September 30, 2013 12:47:00 PM UTC+2, \"Vladimír Fuka <\"name.surname at wrote:
> > Is there any way to make comparison case-insensitive?
>
>
>
> Just convert it to upper or lower case first?

That is by far the most common way to do it. Here is a sketch (at least untested):

function string_tolower( string ) result (new)
character(len=*) :: string

character(len=len(string)) :: new

integer :: i
integer :: k

length = len(string)
new = string
do i = 1,len(string)
k = iachar(string(i:i))
if ( k >= iachar('A') .and. k <= iachar('Z') ) then
k = k + iachar('a') - iachar('A')
new(i:i) = achar(k)
endif
enddo
end function string_tolower

Regards,

Arjen

[y.bi...@googlemail.com]

Thanks!

[Paul van Delst]

On 09/30/13 06:56, Arjen Markus wrote:

> On Monday, September 30, 2013 12:47:00 PM UTC+2, \"Vladim�r Fuka <\"name.surname at wrote:
>>> Is there any way to make comparison case-insensitive?
>>
>>
>>
>> Just convert it to upper or lower case first?
>
> That is by far the most common way to do it. Here is a sketch (at least untested):
>
> function string_tolower( string ) result (new)
> character(len=*) :: string
>
> character(len=len(string)) :: new
>
> integer :: i
> integer :: k
>
> length = len(string)
> new = string
> do i = 1,len(string)
> k = iachar(string(i:i))
> if ( k >= iachar('A') .and. k <= iachar('Z') ) then
> k = k + iachar('a') - iachar('A')
> new(i:i) = achar(k)
> endif
> enddo
> end function string_tolower

Just because, here's mine:


MODULE String_Utility
IMPLICIT NONE
PRIVATE
PUBLIC :: StrLowCase

! List of character for case conversion
CHARACTER(*), PARAMETER :: LOWER_CASE = 'abcdefghijklmnopqrstuvwxyz'
CHARACTER(*), PARAMETER :: UPPER_CASE = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

CONTAINS

FUNCTION StrLowCase( Input_String ) RESULT( Output_String )
CHARACTER(*), INTENT(IN) :: Input_String
CHARACTER(LEN(Input_String)) :: Output_String
INTEGER :: i, n

! Copy input string
Output_String = Input_String

! Convert case character by character
DO i = 1, LEN(Output_String)
n = INDEX(UPPER_CASE, Output_String(i:i))
IF ( n /= 0 ) Output_String(i:i) = LOWER_CASE(n:n)
END DO
END FUNCTION StrLowCase

END MODULE String_Utility


Shamelessly cribbed from:

! Figure 3.5B, pg 80, "Upgrading to Fortran 90", by Cooper Redwine,
! 1995 Springer-Verlag, New York.

It's worked pretty good so far (since 1995 :o)

cheers,

paulv

[gera...@rrt.net]

The above code is ASCII dependent.
_______________________________________ Gerard Schildberger

[Paul van Delst]

On 09/30/13 14:51, gera...@rrt.net wrote:
> On Monday, September 30, 2013 5:56:44 AM UTC-5, Arjen Markus wrote:

[Arjen's code snipped]

> The above code is ASCII dependent.

Yes. But that's good, right? Arjen's use of IACHAR and ACHAR means the
ASCII collating sequence -- which doesn't change -- is being used. Even
if you're on a non-ASCII machine (EBCDIC?)

Now, if he used ICHAR and CHAR (which uses the "processor" collating
sequence) we'd have a discussion.

:o)

cheers,

paulv

[Richard Maine]

Well.... there's a discussion anyway - just a different one than what
you were probably thinking of.

Yes, the use of IACHAR means that the code will work the same way
regardless of the processor's native collating sequence. But what it
doesn't cover is the question of whether the code always does what one
wants, which is a somewhat different one.

There are character sets that have alphabetic characters other than 'A'
to 'Z'. Even if we stick with ... ah, I'm not sure of the right term...
tempted to say Roman-based, but I'm not sure that's quite right... in
any case, character sets that include 'A' to 'Z' as the Fortran default
character kind is required to do, you still have the matter of various
accented characters, which sometimes have upper-and lower-case variants.

I recall once suggesting that the language ought to include things like
case conversion and case-insensitive comparison as standard intrinsics.
The answer I got was that the subject was more complicated than had
occurred to me in my English-centric thinking, and that those
complications were why it was not part of the standard.

So I have my own versions of those functions, just like many other
people do. I have to admit that my versions share the same shortcomming
of handling only the 26 letters that we use in English, but at least I
now am aware of that as a shortcomming.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:

> Paul van Delst <paul.v...@noaa.gov> wrote:

(snip)

>> Yes. But that's good, right? Arjen's use of IACHAR and ACHAR means the
>> ASCII collating sequence -- which doesn't change -- is being used. Even
>> if you're on a non-ASCII machine (EBCDIC?)

(snip)

> Well.... there's a discussion anyway - just a different one than what
> you were probably thinking of.

> Yes, the use of IACHAR means that the code will work the same way
> regardless of the processor's native collating sequence. But what it
> doesn't cover is the question of whether the code always does what one
> wants, which is a somewhat different one.

> There are character sets that have alphabetic characters other than 'A'
> to 'Z'. Even if we stick with ... ah, I'm not sure of the right term...
> tempted to say Roman-based, but I'm not sure that's quite right... in
> any case, character sets that include 'A' to 'Z' as the Fortran default
> character kind is required to do, you still have the matter of various
> accented characters, which sometimes have upper-and lower-case variants.

I am not sure of the specific term, either. In C, it is called
locale, and can be set through an environment variable.

I do remember that it is the reason that PL/I allows @, #, and $ to
be letters. In other alphabets, those code positions can be replaced
by actual letters. That is, for actually writing programs.

Java uses Unicode as its native characters set. Any Unicode letter
can be used to start a variable (or other identifier) name, and
any Unicode letter or digit to continue one. There are characters
that look exactly like the usual English alphabet characters, but
have different code points. There are also methods in the Character
class like isLetter() or isUpperCase() to do the appropriate test
on any Unicode character.

> I recall once suggesting that the language ought to include things like
> case conversion and case-insensitive comparison as standard intrinsics.
> The answer I got was that the subject was more complicated than had
> occurred to me in my English-centric thinking, and that those
> complications were why it was not part of the standard.

But yes, without Unicode it is complicated. When there were only 128
or so characters, those were reused for different languages.
Reading the character code is not enough to tell which is which.
Seems to me that along with C interoperability they could have
added the C locale specific parts.

> So I have my own versions of those functions, just like many other
> people do. I have to admit that my versions share the same shortcomming
> of handling only the 26 letters that we use in English, but at least I
> now am aware of that as a shortcomming.

-- glen

[William Clodius]

In practice it is a shorctoming of the Fortran character type. The only
letters guaranteed to be representable are those of ASCII. In practice I
would expect Fortran processors to not check the contents of character
strings with appropriate settings, so you could probably open any binary
file as text and store the results in the string, but the interpretation
of that string would be context dependent. The same binary contents
would differ depending on whether the file is UTF-8, UTF-16, ISO/IEC
8859-n, etc.

The normal way to handle this would be to have file reader for each type
of file and store the contents in a common format, of which the obvious
is UTF-32. This common format in turn could regularize the data ensuring
a consistent representation of such variants as accented letters. In
principle the default Fortran character kind could be used for this by
putting each UTF character in a fixed number of characters, e.g. 4, but
three is also doable as the character set is expected to use no more
than 24 bits, or by using the optional UCS character kind. But Fortrans
character type has an awkward syntax and to some extent semantics for
all these manipulations. The most convenient representation would almost
certainly as an array (or perhaps a list) of integers.

Once you have the representation you then can decide on a library. It
is relatively straight forward, but tedious, to use the Unicode/UCS
character tables to implement "caseles" of "accentless" comparisions, by
not trying to translate characters without a corresponding characater in
the other case or without an accent. In practice the desired character
comparison properties is very context dependent, consider phonebooks
where you wan homonyms placed adjacent regardless of their spellings, or
the German eszet, whose interpretation as a ligature ss or sz depends on
context.

[Terence]

Arjen's suggestion is based on simple ascii-coded english (assuming the
still-valid AE.dipthong and the english form of the u-umlaut are not
present. But of course this will not work for most other european languages
that use a latin-derived alphabet, due to the presence of accented vowels
and even letters (as in Polish and Spanish).

The elementary 'correct' way to compare stings in a non-case sensitive
manner, is to use the table for the desired language table (whether single
byte or more recently two-byte International ) and a map of the indexes for
the lower-to-upper conversions for that language).

Than as suggested, convert the sample strings to the upper case form by
using the index table and compare the final strings.

Most operating systems supply these langauge tables, if you know where to
find them.

[Arjen Markus]

On Tuesday, October 1, 2013 5:55:39 AM UTC+2, Terence wrote:
> Arjen's suggestion is based on simple ascii-coded english (assuming the
> still-valid AE.dipthong and the english form of the u-umlaut are not
> present. But of course this will not work for most other european languages
> that use a latin-derived alphabet, due to the presence of accented vowels
> and even letters (as in Polish and Spanish).
>

Oh, most definitely I presumed an ASCII alphabet. The reason for using IACHAR() was that there is a simple relationship between the uppercase and lowercase versions. (Paul's alternative is what I used to use, but I think it is a bit slower. Which may not even matter in practice.)

It will not work indeed if you go beyond the very basic character set, but if you really want to you have to deal with an enormous can of worms, where the conversion may not even be invertible. Even in Dutch, which does not use
accented letters, unless the words are adopted from another language, there
is a subtlety that most word processors refuse to be aware of: ij is considered a single letter, so its capitalisation is IJ. Unless they happen to be part of two separate syllables, but that happens only very rarely.

I know there are libraries out there that can do the job much better.

Regards,

Arjen

[Tobias Burnus]

Richard Maine wrote:
> I recall once suggesting that the language ought to include things like
> case conversion and case-insensitive comparison as standard intrinsics.
> The answer I got was that the subject was more complicated than had
> occurred to me in my English-centric thinking, and that those
> complications were why it was not part of the standard.

For instance: What's the lower-case character of "I"? If you write
Turkish or Assabaysanian, it's a dotless "i" (ı) as the capital letter
of "i" with a dot is, well, an "i" with a dot: İ.

In most other languages, you would use I <-> i. Thus, it is not only
complicated but also language dependent.

Tobias

[Terence]

I happened to know of the Dutch 'ij' becuase I can browse it if not speak it
(and never will match some of those unique vowel sounds, even if my
grandchildren are Dutch).
Yes, and Spanish has 'ch' as a single letter in classical contexts, as well
as the use of the cedila over N.

But the situation comes up more often than most programmers may know
In market research in general, the application programs may have to be
capable of parsing (and understanding in the interpretive sense), what
verbal responses are made to what are called 'open questions' where the
answers cannot be anticipated. Software I wrote 'reads and compares' all
latin-based eurpoean languages, Japanese as Romaji, and moderen Greek (in
its unique symbology).

[robin....@gmail.com]

On Tuesday, October 1, 2013 11:07:25 AM UTC+10, glen herrmannsfeldt wrote:

> I do remember that it is the reason that PL/I allows @, #, and $ to be
> letters. In other alphabets, those code positions can be replaced by actual
> letters. That is, for actually writing programs.

PL/I has always been able to perform case-sensitive and case-insensitive
comparisons.

Normally, PL/I performs case-sensitive comparisons.
Originally (1966) case-insensitive comparisons were performed with the help of
the TRANSLATE built-in function.

In the last decade or so, the built-in functions UPPERCASE and LOWERCASE
were added to simplify the process. These enable text to be translated
to an appropriate case before performing the comparison.

[FX]

> I recall once suggesting that the language ought to include things like
> case conversion and case-insensitive comparison as standard intrinsics.
> The answer I got was that the subject was more complicated than had
> occurred to me in my English-centric thinking, and that those
> complications were why it was not part of the standard.

It's a complex issue, but there is a standard dealing with it (Unicode).

--
FX

[FX]

> It's a complex issue, but there is a standard dealing with it (Unicode).

Forgot to add: having access to a Unicode-compliant string manipulation
library is very nice to do scripting if you have to deal with strings.
Python, e.g., does that perfectly. But I suppose string manipulation and
scripting is not really Fortran's forte anyway :)

--
FX

[Louis Krupp]

On Wed, 2 Oct 2013 13:49:12 +1000, "Terence" <tbwr...@bigpond.net.au>
wrote:

>Yes, and Spanish has 'ch' as a single letter in classical contexts, as well
>as the use of the cedila over N.

I believe you're thinking of the tilde
(http://en.wikipedia.org/wiki/Tilde). The cedilla goes under the 'c'
to indicate an 's' sound instead of a 'k' sound:

http://en.wikipedia.org/wiki/Cedilla

Louis

[Terence]

"I believe you're thinking of the tilde"

Lous. Your SO right!
Can't think why I typed that.
Of COURSE it's a tilde (first key top row on US/UK keyboards and others;
but �, � are Alt-164 and 165 on those boards.)!!
My wife and children are all native Spanish-speakers, and I've been speaking
that language daily for 40 years since getting married.

I have to put my error down to having previously worked in French with IBM;
holidayed in Quebec, and now practising again for holidaay in (French) New
Caledonia next month..

[David Thompson]

On Tue, 1 Oct 2013 01:07:25 +0000 (UTC), glen herrmannsfeldt
<g...@ugcs.caltech.edu> wrote:

> Richard Maine <nos...@see.signature> wrote:
<snip>

> > Well.... there's a discussion anyway - just a different one than what
> > you were probably thinking of.

<snip>

> > There are character sets that have alphabetic characters other than 'A'
> > to 'Z'. Even if we stick with ... ah, I'm not sure of the right term...
> > tempted to say Roman-based, but I'm not sure that's quite right... in
> > any case, character sets that include 'A' to 'Z' as the Fortran default
> > character kind is required to do, you still have the matter of various
> > accented characters, which sometimes have upper-and lower-case variants.
>
> I am not sure of the specific term, either. In C, it is called
> locale, and can be set through an environment variable.
>

locale is the mechanism for *any* (more or less) language/country/etc.
C (and POSIX) locale is actually more; charset (thus usually language)
and collation are important parts of a locale, but it also has formats
for representing dates and times, and for numbers especially money
amounts, which also vary around the world. locale is set by a call,
but that call normally does use one or a few environment var(s).

The specific set of 26 (or 52) unaccented letters used for (modern)
English, and not other languages I know, is usually called 'Latin',

> I do remember that it is the reason that PL/I allows @, #, and $ to
> be letters. In other alphabets, those code positions can be replaced
> by actual letters. That is, for actually writing programs.
>
> Java uses Unicode as its native characters set. Any Unicode letter
> can be used to start a variable (or other identifier) name, and
> any Unicode letter or digit to continue one. There are characters
> that look exactly like the usual English alphabet characters, but
> have different code points. There are also methods in the Character
> class like isLetter() or isUpperCase() to do the appropriate test
> on any Unicode character.
>

Ada as of 1995 also requires Unicode support both source and runtime,
although the Ada community's strong emphasis on readability and
clarity of source seems to encourage staying in the ASCII subset.

<snip rest>

[robin....@gmail.com]

On Monday, September 30, 2013 8:39:47 PM UTC+10, y.bi...@googlemail.com wrote:
> Hi all! I need to compare to strings. Fortran can do it with '==' but it is case sensitive. Is there any way to make comparison case-insensitive? Thanks!

PL/I also can compare strings. Comparisons are normally case-sensitive,
but by using the built-in functions UPPERCASE or LOWERCASE,
a case-insensitive compare can be obtained.

[Richard Maine]

David Thompson <dave.th...@verizon.net> wrote:

> On Tue, 1 Oct 2013 01:07:25 +0000 (UTC), glen herrmannsfeldt
> <g...@ugcs.caltech.edu> wrote:
>
> > Richard Maine <nos...@see.signature> wrote:
> > > There are character sets that have alphabetic characters other than 'A'
> > > to 'Z'. Even if we stick with ... ah, I'm not sure of the right term...
> > > tempted to say Roman-based, but I'm not sure that's quite right... in
> > > any case, character sets that include 'A' to 'Z' as the Fortran default
> > > character kind is required to do,

> > I am not sure of the specific term, either. In C, it is called
> > locale, and can be set through an environment variable.

> locale is the mechanism for *any* (more or less) language/country/etc.

That's definitely not the term I was looking for. I was thinking about
the term for that specific class of character sets - not something about
any character set, or even as David notes, things in addition to
character sets that vary from place to place.

> The specific set of 26 (or 52) unaccented letters used for (modern)
> English, and not other languages I know, is usually called 'Latin',

That's probably it. I thought of the term "Latin" but wasn't sure
whether it was quite right. Probably is.

[FX]

> PL/I also can compare strings.

If someone posts a message for every single language that can compare
strings, that thread is going to be very long and quite boring.

--
FX

[Clive Page]

True. But I have to say that Robin's posts have (for me) some
entertainment value. Whenever someone raises some problem in Fortran,
he is sure to post "PL/I can do this". One has come to expect it of him.

Perhaps in some other thread, he would like to explain why PL/I despite
being so good, never replaced Fortran.

--
Clive Page

[FX]

> True. But I have to say that Robin's posts have (for me) some
> entertainment value.

While I do enjoy repitition-based humor as much as the next man, I can't
say that I appreciate it in this particular setting, anymore than I
consider repeated spam funny.

--
FX

[Dan Nagle]

I wonder why Robin never tells us where we could get PL/I compilers
to try on our current personal computers (Win/Mac/Linux) ?

I should mention that my personal computer has a personal-sized budget,
especially for experiments.

--
Cheers!

Dan Nagle

[invalid]

On 2013-10-14, Dan Nagle <danl...@me.com> wrote:
> On 2013-10-14 09:34:44 +0000, Clive Page said:
>
>> On 14/10/2013 10:18, FX wrote:
>>>> PL/I also can compare strings.
>>>
>>> If someone posts a message for every single language that can compare
>>> strings, that thread is going to be very long and quite boring.
>>>
>>
>> True. But I have to say that Robin's posts have (for me) some
>> entertainment value. Whenever someone raises some problem in Fortran,
>> he is sure to post "PL/I can do this". One has come to expect it of
>> him.
>>
>> Perhaps in some other thread, he would like to explain why PL/I despite
>> being so good, never replaced Fortran.

PL/I hasn't replaced Fortran and not even FORTRAN and neither FORTRAN nor
Fortran have replaced PL/I. The simple answer is PL/I does many things well
but the specialist languages COBOL and FORTRAN got there first in their
respective niches. PL/I is a very nice language but it's a man without
a country.

>
> I wonder why Robin never tells us where we could get PL/I compilers
> to try on our current personal computers (Win/Mac/Linux) ?

If you have deep pockets then you can buy a PL/I compiler for Windows
from IBM. Iron Spring PL/I is free right now (in development) and will run
on x86 Linux. Don't know what there is for Mac. You can also get PL/I
compilers for VMS VAX and Alpha from Kednos.

> I should mention that my personal computer has a personal-sized budget,
> especially for experiments.

Then Iron Spring sounds like a good one to try.

[Richard Maine]

Clive Page <use...@page2.eu> wrote:

> On 14/10/2013 10:18, FX wrote:
> >> PL/I also can compare strings.
> >
> > If someone posts a message for every single language that can compare
> > strings, that thread is going to be very long and quite boring.
>
> True. But I have to say that Robin's posts have (for me) some
> entertainment value. Whenever someone raises some problem in Fortran,
> he is sure to post "PL/I can do this". One has come to expect it of him.

My cat can work with strings, and be much more entertaining about it.

> Perhaps in some other thread, he would like to explain why PL/I despite
> being so good, never replaced Fortran.

Argh! No! He'll likely do so, probably involving some conspiracy theory,
and then he'll argue about it at length. Well, at least there's kill
thread. Maybe the political arguments can move over to the same one.

[invalid]

Clive Page <use...@page2.eu> wrote:

> Perhaps in some other thread, he would like to explain why PL/I despite
> being so good, never replaced Fortran.

PL/I is a very good general purpose language, certainly better than
Fortran. It's probably not better than Fortran for the types of applications
most people use Fortran for. PL/I's goodness has nothing to do with
replacing anything, although that was a goal of its designers. Instead, it
stands on its own in a fairly narrow niche between COBOL and FORTRAN/Fortran.

[glen herrmannsfeldt]

Clive Page <use...@page2.eu> wrote:
> On 14/10/2013 10:18, FX wrote:

(snip)

>> If someone posts a message for every single language that can compare
>> strings, that thread is going to be very long and quite boring.

> True. But I have to say that Robin's posts have (for me) some
> entertainment value. Whenever someone raises some problem in
> Fortran, he is sure to post "PL/I can do this".
> One has come to expect it of him.

> Perhaps in some other thread, he would like to explain why PL/I despite
> being so good, never replaced Fortran.

Most likely Robin will come along to answer.

Seems to me, though, that it was too early. Many PL/I features from
the 1960's are now added in Fortran 2003 and 2008. Computers are
fast enough now that the overhead (time and memory used) doesn't
bother us, but they did to many people at the time.

IBM had hoped to replace Fortran (and maybe COBOL) with PL/I.
To not write Fortran compilers for S/360. But it took longer to
write the PL/I compiler. (PL/I (F) is a lot bigger than Fortran G
and H combined.)

At the time (and even sometime later) there was much discussion
about a Fortran V. IBM decided that it wasn't possible to keep
compatability with Fortran IV, and also do what they wanted in
a new language. (Note, for example, that the only arrays in PL/I
are like Fortran assumed shape. There is nothing like assumed size.)

The whole language was (pretty much) designed before the first
compiler was written. The result was a more logical, but not
necessarily efficient language. (PL/I, for example, allows
nested internal procedures. If I remember, even F2008 doesn't
do that.) Features are more self consistent, even though the
cost might be high.

PL/I has the RECURSIVE attribute, so the compiler doesn't need to
generate recursive code without it, but as far as I know all
compilers always generate reentrant code.

Do any Fortran compilers generate non-reentrant code when no
RECURSIVE attribute is used?

The delay in getting the first PL/I compiler out, and even more
until it was running fast enough, and generating fast enough
code, left room for Fortran.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Do any Fortran compilers generate non-reentrant code when no
> RECURSIVE attribute is used?

Well, of course, many pre-f90 compilers did so. Might even be most
pre-f90 compilers. I certainly used Fortran compilers on platforms where
reentrancy would have made for a mess.

And even post f90, an awful lot of compilers (probably even most) still
have at least an option to default local variables to being saved.
That's certainly not reentrant.

[tim prince]

On 10/14/2013 03:57 PM, Richard Maine wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>> Do any Fortran compilers generate non-reentrant code when no
>> RECURSIVE attribute is used?
>
> Well, of course, many pre-f90 compilers did so. Might even be most
> pre-f90 compilers. I certainly used Fortran compilers on platforms where
> reentrancy would have made for a mess.
>
> And even post f90, an awful lot of compilers (probably even most) still
> have at least an option to default local variables to being saved.
> That's certainly not reentrant.
>

ifort still defaults local arrays effectively to SAVE. RECURSIVE is
recommended for procedures likely to be called in threaded context. It
may be safer than depending on compiling all procedures for OpenMP, for
example.

--
Tim Prince

[Dan Nagle]

Hi,

On 2013-10-14 17:28:57 +0000, glen herrmannsfeldt said:

> Clive Page <use...@page2.eu> wrote:
>> On 14/10/2013 10:18, FX wrote:
>
> (snip)
>>> If someone posts a message for every single language that can compare
>>> strings, that thread is going to be very long and quite boring.
>
>> True. But I have to say that Robin's posts have (for me) some
>> entertainment value. Whenever someone raises some problem in
>> Fortran, he is sure to post "PL/I can do this".
>> One has come to expect it of him.
>
>> Perhaps in some other thread, he would like to explain why PL/I despite
>> being so good, never replaced Fortran.
>
> Most likely Robin will come along to answer.

Oh goodie.

I'm most interested to hear how well PL/I objects interact
with PL/I parallelism to build distributed simulations.

--
Cheers!

Dan Nagle

[robin....@gmail.com]

The task was to perform a caseless compare. I merely pointed
that PL/I can do that trivially.

If you want to find out what languages can do that, see rosetta code.

[robin....@gmail.com]

On Tuesday, October 15, 2013 4:28:57 AM UTC+11, glen herrmannsfeldt wrote: >

> Seems to me, though, that it was too early.

I do not think so. It came at the right time.

It was designed for scientific and commercial uses
at a time when the main languages addressed either scientific
uses (e.g., FORTRAN) and commercial uses (e.g., COBOL).

There was a need for general purpose language that would do both,
since not every task could be categorised to be only scienftific
or only commercial.

It was a larger language than Fortran

> Many PL/I features from the 1960's are now added in Fortran 2003 and 2008.
> Computers are fast enough now that the overhead (time and memory used)
> doesn't bother us, but they did to many people at the time.
> IBM had hoped to replace Fortran (and maybe COBOL) with PL/I.
> To not write Fortran compilers for S/360. But it took longer to write the
> PL/I compiler.

Longer than what?

> (PL/I (F) is a lot bigger than Fortran G and H combined.)

Naturally, it was bigger on account of the larger language that
it implemented, compared to the small language that FORTRAN then offered.

> At the time (and even sometime later) there was much discussion about a Fortran V. IBM decided that it wasn't possible to keep compatability with Fortran IV, and also do what they wanted in a new language. (Note, for example, that the only arrays in PL/I are like Fortran assumed shape. There is nothing like assumed size.)

Yet IBM's PL/I in the 1960s could call FORTRAN procedures and pass arrays
a la assumed size.

However, please don't suggest that FORTRAN'S assumed size is something
that should be promoted as a desirable feature. Fortran's assumed size
(and "adjustable dimensions") were responsible for many programming errors.

> The whole language was (pretty much) designed before the first compiler was
> written. The result was a more logical, but not necessarily efficient
> language. (PL/I, for example, allows nested internal procedures.

As does ALGOL. And now Fortran.

> If I remember, even F2008 doesn't do that.) Features are more self consistent, even though the cost might be high. PL/I has the RECURSIVE attribute, so the compiler doesn't need to generate recursive code without it, but as far as I know all compilers always generate reentrant code. Do any Fortran compilers generate non-reentrant code when no RECURSIVE attribute is used?
> The delay in getting the first PL/I compiler out,

IBM's PL/I-F compiler was out in 1966, along with the IBM 360.
(I don't have a date for the D compiler.)

> and even more until it was running fast enough, and generating fast enough
> code, left room for Fortran.

For ordinary work, IBM's PL/I was as fast as their FORTRAN compilers.

In terms of productivity, IBM's PL/I was far superior than their FORTRANs
on account of PL/I's run-time error handling and compile-time diagnostics.

[gera...@rrt.net]

On Monday, October 14, 2013 10:39:58 PM UTC-5, robin...:

Rather, if you want how to find out how a particular language does
that, see a possible entry at Rosetta Code.

Not every task has entries for a language that you may be
interested in, it depends if somebody (or somebodies) wanted
to put in the time and effort on entering a sample program in
a language for a specific task.

The Fortran language has 320 tasks solved (out of 691); PL/I
has 289 tasks solved. This only means that more people have
put in the effort to solve more Rosetta Code problems (tasks),
not that any language is better or easier to code solutions.
COBOL was rather low on entering entries, but somebody(ies)
have been coding programming solutions as of late (137
entries). Some of the programming solutions require a bit of
time and effort to work out and make the program easy to read,
and simple (hopefully) to understand, and with readable
output. I've been entering REXX solutions for over six years
now, with a quite a bit of time at the keyboard (around 540
entries).

Currently, there isn't a Rosetta Code task for caseless
compares. ______________________________ Gerard Schildberger

[robin....@gmail.com]

On Tuesday, October 15, 2013 4:57:42 PM UTC+11, gera...@rrt.net wrote:
> On Monday, October 14, 2013 10:39:58 PM UTC-5, robin...: > On Monday, October 14, 2013 8:18:11 PM UTC+11, FX wrote: > > > PL/I also can compare strings. > > If someone posts a message for every single language that can > > compare strings, that thread is going to be very long and quite boring. > The task was to perform a caseless compare. I merely pointed > that PL/I can do that trivially. > > If you want to find out what languages can do that, see rosetta code. Rather, if you want how to find out how a particular language does that, see a possible entry at Rosetta Code. Not every task has entries for a language that you may be interested in, it depends if somebody (or somebodies) wanted to put in the time and effort on entering a sample program in a language for a specific task. The Fortran language has 320 tasks solved (out of 691); PL/I has 289 tasks solved. This only means that more people have put in the effort to solve more Rosetta Code problems (tasks), not that any language is better or easier to code solutions. COBOL was rather low on entering entries, but somebody(ies) have been coding programming solutions as of late (137 entries). Some of the programming solutions require a bit of time and effort to work out and make the program easy to read, and simple (hopefully) to understand, and with readable output. I've been entering REXX solutions for over six years now, with a quite a bit of time at the keyboard (around 540 entries).
> Currently, there isn't a Rosetta Code task for caseless compares.

The topic of caseless compares has been present in Rosetta for years,
and you'll find it under "String comparisons".