From: Gordon Sande on
On 2010-03-29 20:39:35 -0300, Luka Djigas <ldigas@___gmail___.com> said:

> On Tue, 30 Mar 2010 01:32:37 +0200, Luka Djigas <ldigas@___gmail___.com> wrote:
>
>> On Mon, 29 Mar 2010 22:44:28 +0000 (UTC), glen herrmannsfeldt
>> <gah(a)ugcs.caltech.edu> wrote:
>>
>> !__________________
>> integer :: i=125
>> write(*,100)i
>> 100 format(i3)
>> read(*,*)
>> end
>> !__________________
>>
> Mea culpa. I spoke too soon (and too fast).
> On Intel's compiler, it indeed doesn't do anything ... prints out "125".
> However, on MS Powerstation 4, it gives out "25" after a blank line.
>
> A coleague run this snippet on his machine while we were discussing it
> on MSP4, so I (wrongly)
> assumed Intel would do the same.
>
>
> -- Luka

RTFM! Look at the part about OPEN. If it has somthing on "carriagecontrol"
then you have hit paydirt. Most fortans do nothing but a few will process
unit 6 (by default) to behave like an old time printer by the time it
is displayed on sent to an attached printer. Some will let to set the
processing option (sometimes called "listing") on other units as well.
These are nonstandard features, Also know as extensions.

It is all under extensions and quality of implementation. That is why there
are manuals. Damned nuisances to find when having a beer for your buddies!



From: glen herrmannsfeldt on
Richard Maine <nospam(a)see.signature> wrote:
(snip)

> Yes, they are gone. In a way, they were never in the standard. Yes,
> there were words in the standard about it, but those words were pretty
> much without substantive content. I will give my version below. These
> are my words rather than the standard's, but I claim that they are
> equivalent, if a bit more verbose and... um... informal. :-)

> "Some printers might act like this. (Insert the details here). Others
> might not. It doesn't hecessarily have anything to do with Fortran, as
> the printers might act that way for files created by any language. We
> just thought it might be useful to remind you of it in the Fortran
> standard for some reason. Not that we are going to tell you comparable
> things about any other output devices.

I do wonder if any printers ever actually did that. I know that
the S/360 printers don't. OS/360 (and successors) have two ways
to specify that a file has carriage control information (in addition
to not having it). The options are A and M. A means ASA control
characters, M means machine control characters, the codes actually
sent to the printer. Unlike ASA, where the character specifies
what to do before printing the line, machine characters specify
what to do after printing the line. There are also machine
characters that specify action but don't print anything.

The most popular printer for S/360, the 1403, was originally
part of the IBM 1401 system. Maybe the printer for the 704,
where Fortran originated did, but I would even be surprised
about that one.

(snip)

> And all this stuff might have happened if we hadn't said anything about
> it. If some future committee deletes all this from the standard, the
> same things might continue to happen.

> Don't ask me why we even bothered to mention this is the Fortran
> standard in the first place. Maybe someone said they would vote 'no'
> unless this was in. Seemed harmless enough as it has no effect."

It does seem to have been pretty popular, though, in the Fortran 66
days. I do remember it for terminal output on DEC systems, such
as TOPS-10 and RT-11. VAX/VMS has special file attributes so that
the system knows which files have it and how to print them.

It seems that as terminal and screen output got more popular,
and line printers less popular, the need went away.

-- glen

From: Richard Maine on
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
[about compilers processing carriage control]

> It does seem to have been pretty popular, though, in the Fortran 66
> days. I do remember it for terminal output on DEC systems, such
> as TOPS-10 and RT-11. VAX/VMS has special file attributes so that
> the system knows which files have it and how to print them.

Note those are all DEC related, so that's sort of only one example.
While DEC wasn't the only one to do that, it was a biggie. I believe
there were other examples.

I personally found the behavior very annoying. Since I could neither
control nor determine whether a compiler was going to interpret carriage
control for me, the only way I found to make my codes completely
portable was to be sure to start every line destined for standard output
with a blank. Never use any other carriage control character because it
might get printed. If I always used a blank, it would vary whether or
not the output was shifted over by a column, but I could accept that. It
did mean that I had to keep my lines one shorter than I otherwise might
have been able to get by with.

I was very much in favor of deleting that cruft from the Fortran
standard, though my reasons were different from the ones some other
people expressed. Some people wanted it deleted because they thought it
made the language look out of date. I wanted it deleted so that it would
be easier to write portable code. I figure that with that out of the
language, every vendor will be presured to at least have an option to
leave the output just as it is without doing carriage control
processing. Thus, I ought to be able to assume there is no carriage
control processing and have that work.

Note that adding nonstandard options to the OPEN statement does not
count. I'm talking about options that do not involve making nonstandard
and nonportable changes to the source code.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on
Richard Maine <nospam(a)see.signature> wrote:
(snip, I wrote)
>> It does seem to have been pretty popular, though, in the Fortran 66
>> days. I do remember it for terminal output on DEC systems, such
>> as TOPS-10 and RT-11. VAX/VMS has special file attributes so that
>> the system knows which files have it and how to print them.

> Note those are all DEC related, so that's sort of only one example.
> While DEC wasn't the only one to do that, it was a biggie. I believe
> there were other examples.

Much of my terminal based Fortran was on DEC systems. I do remember
some with Tymshare (I think that is how they spelled it), and
some with a Data General Eclipse, but not enough that I remember
how they did carriage control.

> I personally found the behavior very annoying. Since I could neither
> control nor determine whether a compiler was going to interpret carriage
> control for me, the only way I found to make my codes completely
> portable was to be sure to start every line destined for standard output
> with a blank.

Especially don't start any numbers in column 1 that might have 1
for the first digit... (even more so if you are paying by the page)

> Never use any other carriage control character because it
> might get printed. If I always used a blank, it would vary whether or
> not the output was shifted over by a column, but I could accept that. It
> did mean that I had to keep my lines one shorter than I otherwise might
> have been able to get by with.

I didn't mind so much seeing them in the case where they weren't
used for carriage control.

(snip)

> Note that adding nonstandard options to the OPEN statement does not
> count. I'm talking about options that do not involve making nonstandard
> and nonportable changes to the source code.

One thing that I liked less than putting carriage control characters
in column 1 was putting ASCII control characters directly into
the output. C, at least, has the escape sequences to keep the
characters out of the source file. Otherwise, there are:

1 FORMAT('
')

-- glen
From: Richard Maine on
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Richard Maine <nospam(a)see.signature> wrote:

> > Never use any other carriage control character because it
> > might get printed. If I always used a blank, it would vary whether or
> > not the output was shifted over by a column, but I could accept that. It
> > did mean that I had to keep my lines one shorter than I otherwise might
> > have been able to get by with.
>
> I didn't mind so much seeing them in the case where they weren't
> used for carriage control.

Then I bet your outputs were all intended for yourself personally. Try
explaining the occasional stray characters to a non-programmer user of
your apps. No matter how much you suggest that the user ignore the stray
characters, they will leave a bad impression, likely including at least
half a suspicion that there is something wrong in spite of your claim
that it is all ok. Been there. Done that. It is much better to avoid
having the problem in the first place.

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