Re: gfortran warnings

On 22/02/2012 11:19 p.m., Ian Bush wrote:

> Well they're not part of the standard character set, so you can't write
> standard conforming code using them. At least that's how I understand it.

I wonder why the TAB character is not part of the standard character
set. I've never seen a keyboard without TAB.

Gib Bogle <g.bogle@auckland.ac.nz> wrote:

> On 22/02/2012 11:19 p.m., Ian Bush wrote:
>
> > Well they're not part of the standard character set, so you can't write
> > standard conforming code using them. At least that's how I understand it.
>
> I wonder why the TAB character is not part of the standard character
> set. I've never seen a keyboard without TAB.

I have. And I've used Fortran compilers on computers with character sets
that didn't include a tab or anything comparable. At the time of the f77
standard, there were *MAJOR* players in the Fortran market in that kind
of position; I'm not talking obscure systems that nobody had ever heard
of, but rather some of the biggest players in the market at the time. A
Fortran standard that left out, for example, CDC, would have been a
joke. Not a very funny one, though, and not one that would have had any
chance of passing. I wasn't in the standards business yet at the time,
but I'm very sure of that one.

The standard character set started expanding in f90 and later. For
f2003, it includes all the printable ASCII characters. But it is still
only the printable characters. There are no non-printable ones such as
tab.

You'd also run into compatibility problems with multiple existing
incompatible interpretations of tabs. Not to speak of all the pain of
having code that works differently depending on things invisible in a
printout. That's one of the things I really hate about the "make"
utility; tab is not only allowed, but it means something completely
different from blanks. I think you'll find that you couldn't let tab
into the standard character set without at least some cases of that
(although it doesn't have to be as bad as "make", which is really
awfully bad on the subject). For example, I don't see how to avoid the
problem with tabs versus blanks in literal strings.

Just because your keyboard has a tab doesn't mean that the ASCII tab
character has to go into your source code. As Ian mentioned, there are
plenty of editors that will allow you to use the tab key, but will put
an "appropriate" (for some definition - sometimes configurable and
context dependent) number of blanks into the file instead of a literal
tab character. That's what I'm used to having.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

On 2012-02-23 7:24 AM, Gib Bogle wrote:
> On 22/02/2012 11:19 p.m., Ian Bush wrote:
>
>> Well they're not part of the standard character set, so you can't write
>> standard conforming code using them. At least that's how I understand it.
>
> I wonder why the TAB character is not part of the standard character
> set. I've never seen a keyboard without TAB.

But have you ever seen a tab character?

On 23/02/2012 10:46 p.m., Ian Harvey wrote:
> On 2012-02-23 7:24 AM, Gib Bogle wrote:
>> On 22/02/2012 11:19 p.m., Ian Bush wrote:
>>
>>> Well they're not part of the standard character set, so you can't write
>>> standard conforming code using them. At least that's how I understand
>>> it.
>>
>> I wonder why the TAB character is not part of the standard character
>> set. I've never seen a keyboard without TAB.
>
> But have you ever seen a tab character?

No. I've never seen a CR or LF character either.

On 23-2-2012 20:36, Gib Bogle wrote:
> On 23/02/2012 10:46 p.m., Ian Harvey wrote:
>> On 2012-02-23 7:24 AM, Gib Bogle wrote:
>>> On 22/02/2012 11:19 p.m., Ian Bush wrote:
>>>
>>>> Well they're not part of the standard character set, so you can't write
>>>> standard conforming code using them. At least that's how I understand
>>>> it.
>>>
>>> I wonder why the TAB character is not part of the standard character
>>> set. I've never seen a keyboard without TAB.
>>
>> But have you ever seen a tab character?
>
> No. I've never seen a CR or LF character either.

So, are they not allowed in a standard conforming program either?

Erik.

Erik Toussaint <user@example.net.invalid> wrote:

> On 23-2-2012 20:36, Gib Bogle wrote:

> > No. I've never seen a CR or LF character either.
>
> So, are they not allowed in a standard conforming program either?

I'm not entirely sure how rhetorical that question might be intended,
but I'll answer it anyway, just to be on the safe side.

Just like tab, CR and LF are not in the Fortran character set. They are
therefore not allowed in portable code. I occurs to me that you might be
thinking about line terminators, but those are not part of the Fortran
code. Those might be part of the physical representation of the Fortran
source code, but they do not count as being part of the code.

A processor may choose to allow them as other "graphic" characters, but
a portable program could not use them.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Gib Bogle wrote:
> On 22/02/2012 11:19 p.m., Ian Bush wrote:
>
>> Well they're not part of the standard character set, so you can't write
>> standard conforming code using them. At least that's how I understand it.
>
> I wonder why the TAB character is not part of the standard character
> set. I've never seen a keyboard without TAB.

My keyboard has a windows button, but I'm pretty sure this system (not
windows) would not respond properly and would most likely cause demons
to fly out of the users nose.

Having a button on the keyboard or not really has no bearing or
relevance to the funtionality of a character.

On the other hand, tab and backspace seem to run neck and neck for
causing the most grief from a historical perspective. I'm pretty sure
we'll have to find a way to lasting world peace before we settle the
character set issue. Based on the religious wars waged over the tab
char, one could make the argument that excluding it was the single
wisest choice made during the design. Other languages have disagreed
and paid for their hubris.

My personal theory is that if we could collect all the minutes and
manpower spent on tabs, and focus that collected power we could cure
cancer or maybe even the common cold.

Ian Harvey wrote:
> On 2012-02-23 7:24 AM, Gib Bogle wrote:
>> On 22/02/2012 11:19 p.m., Ian Bush wrote:
>>
>>> Well they're not part of the standard character set, so you can't write
>>> standard conforming code using them. At least that's how I understand it.
>>
>> I wonder why the TAB character is not part of the standard character
>> set. I've never seen a keyboard without TAB.
>
> But have you ever seen a tab character?

Last Halloween; I live near a University with apparently far too many
grad students.

On Thu, 23 Feb 2012 13:38:05 -0800, nospam@see.signature (Richard Maine)
wrote:

>Erik Toussaint <user@example.net.invalid> wrote:
>
>> On 23-2-2012 20:36, Gib Bogle wrote:
>
>> > No. I've never seen a CR or LF character either.
>>
>> So, are they not allowed in a standard conforming program either?
>
>I'm not entirely sure how rhetorical that question might be intended,
>but I'll answer it anyway, just to be on the safe side.
>
>Just like tab, CR and LF are not in the Fortran character set. They are
>therefore not allowed in portable code. I occurs to me that you might be
>thinking about line terminators, but those are not part of the Fortran
>code. Those might be part of the physical representation of the Fortran
>source code, but they do not count as being part of the code.
>
>A processor may choose to allow them as other "graphic" characters, but
>a portable program could not use them.

Richard, please, could you elaborate a bit on the difference?

It is an interesting topic, but I'm a bit confused by what do you mean
under "portable code" (in "therefore not allowed in portable code ...")?
Does the compiler take it all as one line, disregarding the line
terminators or ...?

Also, what do you mean under "physical representation"?



-- Luka

Luka Djigas <ldigas@at.gmail.com> wrote:

> On Thu, 23 Feb 2012 13:38:05 -0800, nospam@see.signature (Richard Maine)
> wrote:
>

> >Just like tab, CR and LF are not in the Fortran character set. They are
> >therefore not allowed in portable code. I occurs to me that you might be
> >thinking about line terminators, but those are not part of the Fortran
> >code. Those might be part of the physical representation of the Fortran
> >source code, but they do not count as being part of the code.
> >
> >A processor may choose to allow them as other "graphic" characters, but
> >a portable program could not use them.
>
> Richard, please, could you elaborate a bit on the difference?
>
> It is an interesting topic, but I'm a bit confused by what do you mean
> under "portable code" (in "therefore not allowed in portable code ...")?
> Does the compiler take it all as one line, disregarding the line
> terminators or ...?
>
> Also, what do you mean under "physical representation"?

Aha. Your describing that as "also" pretty much shows me where to go
with my answer. That's not just an "also"; that is the center of the
whole thing.

The Fortran standard talks about source code "lines". In terms of the
standard, a line is an abstract thing (like most things in the
standard). The standard pointedly says nothing about what a source code
line is made of in concrete terms. This is quite deliberate. Source code
lines could, and have been on, punched cards, paper tape, magnetic
tapes, or anything else. Oh yes, and they could be disk files. Those
things are all possible physical representations of the source code
lines. It is entirely up to the compiler (well, "processor" in
standard-speak) to define the relationship between the physical
representation and the abstract Fortran concept - what holes would be
punched in the card, or what bits would be on the disk in order to
represent a line as described in the standard.

The CR and/or LF characters that you'll find in common text file formats
today are just part of that physical representation. They are how the
compiler keeps track of what is in each line. They are not part of the
line as described by the standard. They are instead part of the physical
representation. That's the stuff that the standard says nothing about.

If, to take the usual Unix convention for example, the compiler uses an
LF as part of its physical representation of a line, then you aren't
going to be able to have an LF that's part of the abstract line
described by the Fortran standard. That's because if you try, it will
look like the end of the line instead of like something in the content
of the line. (Yes, there could be ways to "escape" that, but the usual
Unix convenstion doesn't). On the other hand, there are file formats
where there is no particular problem in having an LF character. The
record size headers typical of sequential unformatted files alow the
record to contain completely arbitrary content, including LF characters.
There exist systems that use formats like that for text files as well as
for unformatted ones.

As for what I mean by "portable code".... well, I'd hope that was
largely self-evident. Portable code is code that you can easily move
(aka port) from one system to another. There are various degrees of
portable. Depending on context, code might be referred to as portable if
it could be moved from one system to another with relatively small and
simple changes, or it might be called portable only if it could be moved
with no changes at all.

You might be thinking that standard conformance is enough to ensure
portability. If so, you would be wrong. The standard itself is quite
explicit about that. From 1.5, Conformance, in f2003

"Because a standard-conforming program may place demands on a
processor that are not within the scope of the standard or may include
standard items that are not portable,... conformance to this standard
does not ensure that a program will execute consistently on all or any
standard-conforming processors."

If you did have a processor (compiler) that allowed such things as tabs,
CR, and LF in source code lines, that would count as being standard
conforming, but not portable. Please note that I said "in source code
lines." The CR and/or LF that often are used as part of the physical
representation of a source code line do not count as being part of the
source code line. Actually, a tab could also concievably be considered
as part of the physical representation of some number of blanks in the
source code line, but in that case you'd have a physical representation
that was not necessarily portable. I don't think you'll find that most
compilers treat tabs consistently enough to really count quite like
that, but it is at least possible (easy, even).

I could go on a bit more than this already long reply. There are plenty
of related subtleties. But I think that will have to do for now.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

On 2/23/2012 9:42 PM, Richard Maine wrote:
> Luka Djigas<ldigas@at.gmail.com> wrote:
>
>> On Thu, 23 Feb 2012 13:38:05 -0800, nospam@see.signature (Richard Maine)
>> wrote:
>>
>
>>> Just like tab, CR and LF are not in the Fortran character set. They are
>>> therefore not allowed in portable code. I occurs to me that you might be
>>> thinking about line terminators, but those are not part of the Fortran
>>> code. Those might be part of the physical representation of the Fortran
>>> source code, but they do not count as being part of the code.
>>>
>>> A processor may choose to allow them as other "graphic" characters, but
>>> a portable program could not use them.
>>
>> Richard, please, could you elaborate a bit on the difference?
>>
>> It is an interesting topic, but I'm a bit confused by what do you mean
>> under "portable code" (in "therefore not allowed in portable code ...")?
>> Does the compiler take it all as one line, disregarding the line
>> terminators or ...?
>>
>> Also, what do you mean under "physical representation"?
>
> Aha. Your describing that as "also" pretty much shows me where to go
> with my answer. That's not just an "also"; that is the center of the
> whole thing.
>
> The Fortran standard talks about source code "lines". In terms of the
> standard, a line is an abstract thing (like most things in the
> standard). The standard pointedly says nothing about what a source code
> line is made of in concrete terms. This is quite deliberate. Source code
> lines could, and have been on, punched cards, paper tape, magnetic
> tapes, or anything else. Oh yes, and they could be disk files. Those
> things are all possible physical representations of the source code
> lines. It is entirely up to the compiler (well, "processor" in
> standard-speak) to define the relationship between the physical
> representation and the abstract Fortran concept - what holes would be
> punched in the card, or what bits would be on the disk in order to
> represent a line as described in the standard.
>
> The CR and/or LF characters that you'll find in common text file formats
> today are just part of that physical representation. They are how the
> compiler keeps track of what is in each line. They are not part of the
> line as described by the standard. They are instead part of the physical
> representation. That's the stuff that the standard says nothing about.
>
> If, to take the usual Unix convention for example, the compiler uses an
> LF as part of its physical representation of a line, then you aren't
> going to be able to have an LF that's part of the abstract line
> described by the Fortran standard. That's because if you try, it will
> look like the end of the line instead of like something in the content
> of the line. (Yes, there could be ways to "escape" that, but the usual
> Unix convenstion doesn't). On the other hand, there are file formats
> where there is no particular problem in having an LF character. The
> record size headers typical of sequential unformatted files alow the
> record to contain completely arbitrary content, including LF characters.
> There exist systems that use formats like that for text files as well as
> for unformatted ones.
>
> As for what I mean by "portable code".... well, I'd hope that was
> largely self-evident. Portable code is code that you can easily move
> (aka port) from one system to another. There are various degrees of
> portable. Depending on context, code might be referred to as portable if
> it could be moved from one system to another with relatively small and
> simple changes, or it might be called portable only if it could be moved
> with no changes at all.
>
> You might be thinking that standard conformance is enough to ensure
> portability. If so, you would be wrong. The standard itself is quite
> explicit about that. From 1.5, Conformance, in f2003
>
> "Because a standard-conforming program may place demands on a
> processor that are not within the scope of the standard or may include
> standard items that are not portable,... conformance to this standard
> does not ensure that a program will execute consistently on all or any
> standard-conforming processors."
>
> If you did have a processor (compiler) that allowed such things as tabs,
> CR, and LF in source code lines, that would count as being standard
> conforming, but not portable. Please note that I said "in source code
> lines." The CR and/or LF that often are used as part of the physical
> representation of a source code line do not count as being part of the
> source code line. Actually, a tab could also concievably be considered
> as part of the physical representation of some number of blanks in the
> source code line, but in that case you'd have a physical representation
> that was not necessarily portable. I don't think you'll find that most
> compilers treat tabs consistently enough to really count quite like
> that, but it is at least possible (easy, even).
>
> I could go on a bit more than this already long reply. There are plenty
> of related subtleties. But I think that will have to do for now.
>
Perhaps, an examination of the role of CR and LF from a historical point
would help. Before the advent of teletype and CRT terminals,
card-readers were used for source code input. What we call a line of
source code now was a card and, therefore, no CR or LF was needed. A
thin film of air was enough to separate cards.

In such a scenario, CR and LF entered the picture only when source code
and program output were output to a line-printer. If the output was to a
card-punch, CR and LF were not in the picture.

I remember struggling with the concept of a "permanent file system" with
a tree-structure and making unsuccessful attempts to visualize the file
system in terms of card-decks, when such a "new-fangled" system replaced
an older, card-oriented computer system at a university computer center.

-- mecej4

mecej4 <mecej4@nospam.operamail.com> wrote:
(snip)

>>> Also, what do you mean under "physical representation"?

(snip)
>> The CR and/or LF characters that you'll find in common text file formats
>> today are just part of that physical representation. They are how the
>> compiler keeps track of what is in each line. They are not part of the
>> line as described by the standard. They are instead part of the physical
>> representation. That's the stuff that the standard says nothing about.

(snip)
> Perhaps, an examination of the role of CR and LF from a historical
> point would help. Before the advent of teletype and CRT terminals,
> card-readers were used for source code input. What we call a line of
> source code now was a card and, therefore, no CR or LF was needed. A
> thin film of air was enough to separate cards.

> In such a scenario, CR and LF entered the picture only when source code
> and program output were output to a line-printer. If the output was to a
> card-punch, CR and LF were not in the picture.

Card readers, punches, and line printers used by IBM, at least through
S/360, didn't use CR or LF. A line (record) was transfered with
one channel command. I have printed lines with CR and LF on
the 1403, and each prints just like a single blank.

> I remember struggling with the concept of a "permanent file system" with
> a tree-structure and making unsuccessful attempts to visualize the file
> system in terms of card-decks, when such a "new-fangled" system replaced
> an older, card-oriented computer system at a university computer center.

Many DEC systems were designed around teletype terminals and paper
tape readers, using usually CRLF line terminators. That was inherited
by CP/M and then MS-DOS.

IBM terminals like the 2741 don't use ASCII or EBCDIC, and do have
some kind of CR character.

-- glen

On Sat, 25 Feb 2012 08:20:01 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

> mecej4 <mecej4@nospam.operamail.com> wrote:
> (snip)
>
> >>> Also, what do you mean under "physical representation"?
>
> (snip)
> >> The CR and/or LF characters that you'll find in common text file formats
> >> today are just part of that physical representation. They are how the
> >> compiler keeps track of what is in each line. They are not part of the
> >> line as described by the standard. They are instead part of the physical
> >> representation. That's the stuff that the standard says nothing about.
>
> (snip)
> > Perhaps, an examination of the role of CR and LF from a historical
> > point would help. Before the advent of teletype and CRT terminals,
> > card-readers were used for source code input. What we call a line of
> > source code now was a card and, therefore, no CR or LF was needed. A
> > thin film of air was enough to separate cards.
>
> > In such a scenario, CR and LF entered the picture only when source code
> > and program output were output to a line-printer. If the output was to a
> > card-punch, CR and LF were not in the picture.
>
> Card readers, punches, and line printers used by IBM, at least through
> S/360, didn't use CR or LF. A line (record) was transfered with
> one channel command. I have printed lines with CR and LF on
> the 1403, and each prints just like a single blank.
>
Yes, also HT and BS and probably more I didn't run into.

2780/3780 bisync protocol could transmit F-E codes like CR within a
'card' or 'line' but not comm codes like STX unless you had the
'transparency' feature. But I don't know what real hardware did with
them once received; I worked almost entirely with emulators where it
was software that had to cope -- and sometimes didn't.

327x bisync could transmit at least CR LF and IIRC HT to a (nominally)
remote printer, and my doc said they could 'display' on the screen as
blanks before printing but I never had occasion to try that. This may
well have been dependent on the particular device(s), as over several
decades 3270s went through pretty major changes while maintaining an
amazing, even frightening, level of compatibility.

SNA versions of both 3780 and 327x could of course transmit any
character, but it was still up to the device(s) what to do with them.

> > I remember struggling with the concept of a "permanent file system" with
> > a tree-structure and making unsuccessful attempts to visualize the file
> > system in terms of card-decks, when such a "new-fangled" system replaced
> > an older, card-oriented computer system at a university computer center.
>
Imagine a connected maze of bookshelves with decks placed on them
seemingly at random -- or perhaps decks in paper shrouds that prevent
you from seeing the handy markings on the 12-edge. <G>

> Many DEC systems were designed around teletype terminals and paper
> tape readers, using usually CRLF line terminators. That was inherited
> by CP/M and then MS-DOS.
>
Treating teletype as a generic (which really we shouldn't) yes, plus
to a significant extent 'glass TTY' video terminals using the same
ASCII charset and line protocols. Other minis I saw like DG, HP, Prime
used the same terminals but I don't know about file formats.

> IBM terminals like the 2741 don't use ASCII or EBCDIC, and do have
> some kind of CR character.
>
2741 used PTTC which had a combined CRLF aka NewLine code. The
Selectric mechanism couldn't do CR; to move left on the same line you
used multiple backspaces. I worked at a place with magtape Selectrics
(MT/ST) which were also automatic, but not remote; same issue.