FORTRAN IV program illustrating assigned GO TO on web site
Quadibloc
one of several different projections.
This was back when computer time cost money, so I did not want to
contend with the overhead of a subroutine call in an inner loop.
The program, therefore, uses the assigned GO TO instead.
If you want a glance at what FORTRAN looked like in the bad old days,
http://www.quadibloc.com/comp/fort03.htm
John Savard
glen herrmannsfeldt
> Many years ago, I wrote a program to draw a map of the world in any
> one of several different projections.
> This was back when computer time cost money, so I did not want to
> contend with the overhead of a subroutine call in an inner loop.
> The program, therefore, uses the assigned GO TO instead.
I believe that was the original purpose of assigned GO TO,
as it existed even before SUBROUTINE and CALL.
Also, possibly the reason for extended range of DO.
-- glen
Sjouke Burry
Richard Maine
> I successfully forgot about goto a least 30 years ago.
Presumably not in Fortran, then. That would have had to be F66 or
earlier. (F77 wasn't actually published until April of 1978, and it was
a while after that before compilers were out. That could count as almost
30 years, but not "at least" 30 years.) I'd have thought it pretty
awkward to program in F66 without the use of even a single goto;
possible, but darned awkward. I suppose you might have been using a
Fortran variant like Ratfor.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Sjouke Burry
> Sjouke Burry <burrynu...@ppllaanneett.nnlll> wrote:
>
>> I successfully forgot about goto a least 30 years ago.
>
> Presumably not in Fortran, then. That would have had to be F66 or
> earlier. (F77 wasn't actually published until April of 1978, and it was
> a while after that before compilers were out. That could count as almost
> 30 years, but not "at least" 30 years.) I'd have thought it pretty
> awkward to program in F66 without the use of even a single goto;
> possible, but darned awkward. I suppose you might have been using a
> Fortran variant like Ratfor.
>
F66/asm pdp2/pdp11/microvax
F?? ibm186/286
f77 468/p??
C 468 and higher after that.
Basic/fortran/lisp at Arc risc pc(arc 310)
And I kind of disliked goto on all of them.
mecej4
> F2/asm pdp 7
> F66/asm pdp2/pdp11/microvax
> F?? ibm186/286
> f77 468/p??
> C 468 and higher after that.
> Basic/fortran/lisp at Arc risc pc(arc 310)
> And I kind of disliked goto on all of them.
You may not enjoy this article, then: D.E. Knuth, "Structured
Programming with the GOTO Statement," Computing Surveys, vol. 6, 1974.
--mecej4
Terence
While selecting my MSc thesis topic, my professor (Dean, Dr. Baralt)
showed me an article in a computer journal and asked me in all
seriousness what I thought of the title and contents.
It was "Structured Programming with the COMEFROM Statement".
I had to explain that although it was not dated April, it was however,
a well-written spoof on this mentioned article.
Richard Maine
> It was "Structured Programming with the COMEFROM Statement".
> I had to explain that although it was not dated April, it was however,
> a well-written spoof on this mentioned article.
The Elxsi compiler in the mid 80's actually implemented the comefrom
statement (and several variants) as a continuation of this spoof. It
wasn't documented, but I found out about it when Ralph Merkle (one of
the developers) suggested that I might be amused by looking at a certain
area in the compiler executable file. When I did so, I found a list of
strings containing mostly familliar Fortran keywords. Amidst those, I
spotted comefrom. A quick check verified that the statement actually
compiled and worked as "expected".
I later heard that the statement was pulled from the compiler after a
customer submitted a bug report (I think it was a
performance/optimization issue) related to the comefrom statement
implementation. The joke wasn't worth actually investing scarce support
resources on.
glen herrmannsfeldt
(snip)
> It was "Structured Programming with the COMEFROM Statement".
> I had to explain that although it was not dated April, it was however,
> a well-written spoof on this mentioned article.
The problem with COMEFROM is that it isn't so obvious if the
COME FROM is before or after the referenced statement is executed.
At least it seems less obvious than GO TO.
It seems a little convenient to COME FROM before the specified
statement is executed, in which case you can do something like:
COME FROM 123
WRITE(*,*) X,Y,Z
GOTO 123
at some convenient place, such as the end of the program, for
debugging purposes. The OS/360 Fortran G compiler has a debugging
system that works in a similar way with the AT statement.
-- glen
RadSurfer
Attempting to compile that source using gfortran 4.3.0, using an
extension of
".f" and no -std overrides, produced the following.
Has anyone taken the time to make this program compile under a modern
compiler?
Or is that left to us as an exercise :-) Please let me know if anyone
has this
updated... thanks.
[RadSurfer@centos fortran]$ gfortran drawmaps.f
drawmaps.f:2.32:
REAL BUF(60),DTR/Z3F477D1B/,RTD/
Z42394BB8/
1
Error: Symbol 'z3f477d1b' must be a PARAMETER in DATA statement at (1)
drawmaps.f:9.17:
LOGICAL*1 $(1)/
1H*/
1
Error: Invalid character in name at (1)
drawmaps.f:14.72:
ASSIGN 4406 TO
IFIRS
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:20.72:
90801 ASSIGN 272 TO
ITCL
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:21.72:
ASSIGN 4404 TO
ITC2
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:23.72:
90802 ASSIGN 373 TO
ITCL
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:24.72:
ASSIGN 4401 TO
ITC2
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:26.18:
CALL
CREPLY(&875)
1
Error: Syntax error in argument list at (1)
drawmaps.f:28.72:
ASSIGN 575 TO
IQIZ
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:31.13:
READ(5,$,END=909)AMR,AAR,AMS
1
Error: Syntax error in READ statement at (1)
drawmaps.f:33.13:
READ(5,$)PLEN
1
Error: Syntax error in READ statement at (1)
drawmaps.f:37.13:
READ(5,$)IPROJ
1
Error: Syntax error in READ statement at (1)
drawmaps.f:39.13:
READ(5,$)ILAI,ILOI
1
Error: Syntax error in READ statement at (1)
drawmaps.f:43.13:
READ(5,$)IGTO
1
Error: Syntax error in READ statement at (1)
drawmaps.f:45.72:
875 ASSIGN 878 TO
IQIZ
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:49.13:
878
READ(5,$,END=909)AMR,AAR,AMS,PLEN,IPROJ,ILAI,ILOI,IGTO
1
Error: Syntax error in READ statement at (1)
drawmaps.f:54.13:
READ(5,$)ASPE
1
Error: Syntax error in READ statement at (1)
drawmaps.f:59.16:
GO TO ITC2,
(4401,4404)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:60.17:
4401 GO TO IFIRS,
(4400,4406)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:68.72:
4406 ASSIGN 4400 TO
IFIRS
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:97.72:
ASSIGN 401 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:107.72:
ASSIGN 402 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:118.72:
ASSIGN 403 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:129.72:
ASSIGN 404 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:140.72:
ASSIGN 405 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:145.72:
ASSIGN 406 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:157.72:
ASSIGN 407 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:177.72:
ASSIGN 65 TO
IQIC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:185.72:
ASSIGN 408 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:188.72:
608 ASSIGN 409 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:189.72:
609 ASSIGN 410 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:190.72:
610 ASSIGN 411 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:191.72:
611 ASSIGN 412 TO
IPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:193.72:
ASSIGN 82 TO
ILAC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:200.72:
ASSIGN 86 TO
ILAC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:202.72:
376 ASSIGN 205 TO
IPPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:208.72:
ASSIGN 85 TO
IQIC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:229.6:
BUF(1)=FLOAT(IHX)/
10.
1
Error: Unclassifiable statement at (1)
drawmaps.f:230.6:
BUF(2)=FLOAT(IHY)/
10.
1
Error: Unclassifiable statement at (1)
drawmaps.f:235.6:
BUF(1)=FLOAT(IHX)/
10.
1
Error: Unclassifiable statement at (1)
drawmaps.f:236.6:
BUF(2)=FLOAT(IHY)/
10.
1
Error: Unclassifiable statement at (1)
drawmaps.f:238.6:
7 BUF(J+2)=BUF(J)+FLOAT(IBF(J)-128)/
10.
1
Error: Unclassifiable statement at (1)
drawmaps.f:240.72:
J=1
1
drawmaps.f:237.72:
DO 7
J=1,IP
2
Error: Variable 'j' at (1) cannot be redefined inside loop beginning
at (2)
drawmaps.f:251.72:
99 ASSIGN 215 TO
IPPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:257.72:
ASSIGN 65 TO
IQIC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:267.72:
ASSIGN 225 TO
IPPR
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:271.72:
ASSIGN 65 TO
IQIC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:282.16:
GO TO ITCL,
(272,373)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:284.16:
373 GO TO
IQIZ(878,676,575)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:295.16:
GO TO ILAC,
(86,82)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:315.16:
GO TO IQIC,
(65,75,85,95)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:322.15:
GO TO IPR,
(401,402,403,404,405,406,407,408,409,410,411,412)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:342.6:
Y-YZR+RAD-SQRT(RAD*RAD-
X*X)
1
Error: Unclassifiable statement at (1)
drawmaps.f:357.72:
ASSIGN 90 TO
IQIC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:393.72:
660 ASSIGN 75 TO
IQIC
1
Warning: Deleted feature: ASSIGN statement at (1)
drawmaps.f:401.16:
GO TO IPPR,
(205,215,225,2670)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drawmaps.f:419.6:
END
1
Error: END DO statement expected at (1)
Error: Unexpected end of file in 'drawmaps.f'
[RadSurfer@centos fortran]$
You could just feel the years that have past with each error
statement, lol.
I wonder if 'g95' compiler fairs any better with this type code?
//RadSurfer//
OCTAVE 2.913 now installed in CentOS 5. Yaay for me.
Tim Prince
> On Aug 12, 3:18 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>> Many years ago, I wrote a program to draw a map of the world in any
>> one of several different projections.
>>
>> This was back when computer time cost money, so I did not want to
>> contend with the overhead of a subroutine call in an inner loop.
>>
>> The program, therefore, uses the assigned GO TO instead.
>>
>> If you want a glance at what FORTRAN looked like in the bad old days,
>>
>> http://www.quadibloc.com/comp/fort03.htm
>>
>> John Savard
>
>
> Attempting to compile that source using gfortran 4.3.0, using an
> extension of
> ".f" and no -std overrides, produced the following.
>
promoted efficiency. The more usual reason for writing code like this
was to hinder use with an upgraded compiler, without re-employing the
author. That could backfire if the author had to work under a deadline.
Some of the non-standard features used were pre-cursors of stuff which
was adopted in a different form in f90, and others were deleted on
account of their lack of usefulness.
In order to remove assigned goto, you need test cases, and a compiler
which supports the syntax, so that you can test to make sure you haven't
destroyed working functions. Needless to say, you would first fix the
non-standard stuff which doesn't work with that compiler. My method was
to turn them into logical IF and use re-structuring processors to turn
it into f77.
jmfb...@aol.com
Tim Prince <timoth...@sbcglobal.net> wrote:
>RadSurfer wrote:
>> On Aug 12, 3:18 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>>> Many years ago, I wrote a program to draw a map of the world in any
>>> one of several different projections.
>>>
>>> This was back when computer time cost money, so I did not want to
>>> contend with the overhead of a subroutine call in an inner loop.
>>>
>>> The program, therefore, uses the assigned GO TO instead.
>>>
>>> If you want a glance at what FORTRAN looked like in the bad old days,
>>>
>>> http://www.quadibloc.com/comp/fort03.htm
>>>
>>> John Savard
>>
>>
>> Attempting to compile that source using gfortran 4.3.0, using an
>> extension of
>> ".f" and no -std overrides, produced the following.
>>
>I question the author's assertion that all these awkward features
>promoted efficiency. The more usual reason for writing code like this
>was to hinder use with an upgraded compiler, without re-employing the
>author.
HUH? When you have FORTRAN II, you can't use FORTRAN-77
features; you do realize that nobody had thought of those features
yet and, for those features that were comptemplated, there
wasn't enough CPU power, memory nor disk^Wcard storage to
implement it.
> That could backfire if the author had to work under a deadline.
>Some of the non-standard features used were pre-cursors of stuff which
>was adopted in a different form in f90, and others were deleted on
>account of their lack of usefulness.
>In order to remove assigned goto, you need test cases, and a compiler
>which supports the syntax, so that you can test to make sure you haven't
>destroyed working functions. Needless to say, you would first fix the
>non-standard stuff which doesn't work with that compiler. My method was
>to turn them into logical IF and use re-structuring processors to turn
>it into f77.
I thought it was a cool thing for some "kid" to take that old code
and see what happened with a modern fancy schmancy compiler. That
"kid" has imagination and curiosity and enough perverseness to
have bit god potential.
/BAH
Quadibloc
> Has anyone taken the time to make this program compile under a modern
> compiler?
No... and yes.
http://www.quadibloc.com/maps/mapper.txt
is a *similar* program, but instead of trying to use a Tektronix 4010
or a Calcomp plotter, it generates .BMP files.
It uses map data that is readily available (described on the page
http://www.quadibloc.com/maps/mapint.htm
as being from GSHSS and GMT) and it supports lots more projections.
John Savard
Quadibloc
> > > F2/asm pdp 7
> > > F66/asm pdp2/pdp11/microvax
> > > F?? ibm186/286
> > > f77 468/p??
> > > C 468 and higher after that.
> > > Basic/fortran/lisp at Arc risc pc(arc 310)
> > > And I kind of disliked goto on all of them.
> > You may not enjoy this article, then: D.E. Knuth, "Structured
> > Programming with the GOTO Statement," Computing Surveys, vol. 6, 1974.
Clearly, if you don't have structured control statements, you can use
what a language does have in a disciplined manner. And because the
classic structured control structures are almost always what one needs
- most programs followed Donald Knuth's advice even before he wrote
it!
My FORTRAN IV example was one of the rare exceptions.
> While selecting my MSc thesis topic, my professor (Dean, Dr. Baralt)
> showed me an article in a computer journal and asked me in all
> seriousness what I thought of the title and contents.
> It was "Structured Programming with the COMEFROM Statement".
> I had to explain that although it was not dated April, it was however,
> a well-written spoof on this mentioned article.
And, of course, the COME FROM statement owes its origins to
"A Linguistic Contribution to GO TO-less Programming"
which _did_ appear in an April issue of DATAMATION.
John Savard
Quadibloc
> I question the author's assertion that all these awkward features
> promoted efficiency. The more usual reason for writing code like this
> was to hinder use with an upgraded compiler, without re-employing the
> author.
This program was written strictly for my own personal use, and thus
when I say I used the assigned GO TO for the sake of efficiency, I can
do so with a clear conscience.
Having also written a random number generating routine in 360
Assembler to be called from FORTRAN, I knew *exactly* what goes into a
subroutine call on that machine.
John Savard
Quadibloc
His complaint is not unfair in that particular way.
What I had was FORTRAN IV, and it certainly did have subroutine calls.
The program has control flows which don't correspond well to the
structured programming paradigm - they couldn't even be made into a
CASE statement - because the point plotting code is treated like a
subroutine, "called" from either the 'draw the map from the coastlines
file' or the 'draw the graticule' part of the program.
The other stuff can be fixed. Messy control flows that handle "did the
last point force me to draw to the current point with the pen up" can
be handled with a boolean flag: I'm using one of my assigned GOTOs to
do that job.
Why not just change the jump directly, instead of changing a flag and
then having an IF, I asked myself in all innocence.
John Savard
mecej4
> Terence <tbwr...@cantv.net> wrote:
>
>> It was "Structured Programming with the COMEFROM Statement".
>> I had to explain that although it was not dated April, it was however,
>> a well-written spoof on this mentioned article.
>
> The Elxsi compiler in the mid 80's actually implemented the comefrom
> statement (and several variants) as a continuation of this spoof. It
> wasn't documented, but I found out about it when Ralph Merkle (one of
> the developers) suggested that I might be amused by looking at a certain
> area in the compiler executable file. When I did so, I found a list of
> strings containing mostly familliar Fortran keywords. Amidst those, I
> spotted comefrom. A quick check verified that the statement actually
> compiled and worked as "expected".
>
> I later heard that the statement was pulled from the compiler after a
> customer submitted a bug report (I think it was a
> performance/optimization issue) related to the comefrom statement
> implementation. The joke wasn't worth actually investing scarce support
> resources on.
>
unconditional COMEFROM?
-- mecej4
Richard Maine
> Richard Maine wrote:
> >
> > The Elxsi compiler in the mid 80's actually implemented the comefrom
> > statement (and several variants)...
> >
> Were Computed and Assigned COMEFROM implemented, as well, or just an
> unconditional COMEFROM?
Yes, as I recall, I was told they were also implemented, although I
don't think I went to the trouble of checking that. That was the "and
several variants" I referred to.
Peter Flass
Most compilers warn about obsolete features. Few actually refuse to
compile them, unless they conflict with some newer feature. Somebody
should just add the code back in...
Peter Flass
Did you try Watcom FORTRAN? What does it do with this code?
Walter Bushell
Peter Flass <Peter...@Yahoo.com> wrote:
> Most compilers warn about obsolete features. Few actually refuse to
> compile them, unless they conflict with some newer feature. Somebody
> should just add the code back in...
No, nobody wants programmers writing code with assigned GOT Os today.
You just have to remove them from any code. Regular GOT Os probably have
to be allowed because of the mathematical subroutine libraries that have
been developed.
Peter Flass
You may be right in principle, but I still say this is arrogance on the
part of the compiler writer. If someone has a working program, no
matter how old, for the compiler writer to arbitrarily decide they have
to "fix" it to fit somebody's notion of proper programming practices is
just plain wrong. Most compilers jump through hoops to support even
code that took advantage of bugs in older systems. Warning/error
messages are fine, but I still say that unless it's impossible to
support some old feature every attempt should be made to obviate the
need to change working code.
jmfb...@aol.com
My most favorite style of programming was to have a table
that I JRSTed through (or PUSHJed) based on a value which,
by design, was also the index into the table. The table
was a bunch of addresses that also happened to be labels
of routines. Then to change the "format" of the calling
sequences, all I had to do was edit the table. That left
all my bugs (after testing the code) concentrated in my
editing the table instead of obscure typos of ACs and
variables and opcodes all over my address space.
I'd use the computed goto's in a nanosecond. There just
weren't enough of them. If I was limited by having to the
compiler, the computed gotos would probably be the first
piece of a matrix. The second elements would also be a set
of gotos...and so on.
Oh, I'm getting a ripple of fission down my back just thinking
of the beauty of the program flow. I haven't had this feeling
in a long time.
/BAH
jmfb...@aol.com
I have severe trouble accepting a "NO GOTO" policy in any computing
enviornment. But then we earned our keep based on an interrupt
driven OS.
/BAH
jmfb...@aol.com
IOW, JMF's rule number one...Don't fix what ain't broke.
/BAH
Richard Maine
> Walter Bushell wrote:
>
> > In article <46c0d2de$0$4663$4c36...@roadrunner.com>,
> > Peter Flass <Peter...@Yahoo.com> wrote:
> >
> >>Most compilers warn about obsolete features. Few actually refuse to
> >>compile them, unless they conflict with some newer feature. Somebody
> >>should just add the code back in...
> >
> > No, nobody wants programmers writing code with assigned GOT Os today.
>
> You may be right in principle, but I still say this is arrogance on the
> part of the compiler writer....
> Most compilers jump through hoops to support even
> code that took advantage of bugs in older systems. Warning/error
> messages are fine, but I still say that unless it's impossible to
> support some old feature every attempt should be made to obviate the
> need to change working code.
I think you ascribe other people's expressed attitudes to compiler
writers. There aren't actually very many currently supported compilers
that have direct roots back to the days when assigned GOTO was in the
language. It isn't a matter of "adding the code back in" to the
compiler. It is more a matter of putting it in in the first place. And
doing assigned GOTO in a way that conformed to the old standard has
"nontrivial" aspects on today's machines, where an address might well
not fit in a default integer. My second-hand understanding is that the
"usual" implementation trick involved shadow variables (I think that's
what they were called), where each integer variable used for an assigned
goto had two separate copies of different sizes - one for when it was
used as a statement label, and one for other uses.
Besides which, there is a bit of a cost/benefit problem. The benefit
side is questionable because in my observation, most codes of that
vintage were written quite nonportably anyway. Most programmers of that
era paid little attention to standards and portability. I'm quite sure
there were notable exceptions, but my personal observation is that the
majority of code of that era had little chance of surviving machine
changes ithout significant porting work anyway. (I used to do a lot of
thaty porting work; the scars prompted my later interest in standards.)
If I recall skimming the error messages in the code in question, it
provides an example. It has several things that are not portable. I'm
not even sure I recognized some of them. (I'm a bit of a newbie and
didn't start in Fortran until about 1967, though I did work with some
pre-f66 compilers.)
dpb
...
> If I recall skimming the error messages in the code in question, it
> provides an example. It has several things that are not portable. I'm
> not even sure I recognized some of them. (I'm a bit of a newbie and
> didn't start in Fortran until about 1967, though I did work with some
> pre-f66 compilers.)
What other usenet group(s) would have a responder note they might be
considered a newbie having begun "only" in 1967? :)
To paraphrase Jeff Foxworthy--"You might be a newbie if... " ? :)
--
Walter Bushell
You say 70-90 rather than 709-0.
You started Fortran with version 4.
You think bytes are _always_ eight bits.
You cannot write Fortran in _any_ language.
You never had 2 week turn around time.
glen herrmannsfeldt
(snip)
> doing assigned GOTO in a way that conformed to the old standard has
> "nontrivial" aspects on today's machines, where an address might well
> not fit in a default integer. My second-hand understanding is that the
> "usual" implementation trick involved shadow variables (I think that's
> what they were called), where each integer variable used for an assigned
> goto had two separate copies of different sizes - one for when it was
> used as a statement label, and one for other uses.
As ASSIGNed GOTO only works within one program unit, which is unlikely
to be larger than 4GB, it would seem to me that an address relative to
the beginning of the program unit would work. It would depend on
the processor, but for many that should work reasonably well.
> Besides which, there is a bit of a cost/benefit problem. The benefit
> side is questionable because in my observation, most codes of that
> vintage were written quite nonportably anyway. Most programmers of that
> era paid little attention to standards and portability. I'm quite sure
> there were notable exceptions, but my personal observation is that the
> majority of code of that era had little chance of surviving machine
> changes ithout significant porting work anyway. (I used to do a lot of
> thaty porting work; the scars prompted my later interest in standards.)
For the case of rare code that is Fortran 66 standard, and includes
ASSIGNed GOTO, it seems reasonable to provide some support. I believe
it wouldn't be too hard to do an automated conversion to computed GOTO,
where the ASSIGN statements would assign a small integer value to be
used with the appropriate computed GOTO statement.
In the program/compiler under discussion, though, ASSIGN and the
assigned GOTO only generated a warning. It seems that they are
supported.
> If I recall skimming the error messages in the code in question, it
> provides an example. It has several things that are not portable. I'm
> not even sure I recognized some of them. (I'm a bit of a newbie and
> didn't start in Fortran until about 1967, though I did work with some
> pre-f66 compilers.)
It seems to be OS/360 Fortran IV, except for the local modification
to allow list directed I/O. OS/360 Fortran (and I believe successor
compilers from IBM) allow $ as a letter in variable names. Some of the
later errors are due to the compiler ignoring earlier statements with
errors. Especially interesting is the message for missing END DO.
-- glen
glen herrmannsfeldt
(snip)
> You say 70-90 rather than 709-0.
As it was explained to me a long time ago, though I never
got to actually use one. It was the transistorized version of
the 709, so was going to be 709T. Now pronounce that.
> You started Fortran with version 4.
Yes. (And always wondered about version 3.)
> You think bytes are _always_ eight bits.
No, but they should be.
> You cannot write Fortran in _any_ language.
I will have to think about that one.
> You never had 2 week turn around time.
I can remember a few days, but not two weeks.
-- glen
Rostyslaw J. Lewyckyj
>
> You say 70-90 rather than 709-0.
>
the designation 709-4
Peter Flass
I think you're right. I'm reading this on a.f.c, not c.l.f. I'm not a
FORTRAN guru, but IIRC the syntax was something like:
go to a,10,20,30,40
...
assign 10 to a
so I would expect that the assign also set the statement address as well
as the value of a.
>
> Besides which, there is a bit of a cost/benefit problem.
The cost/benefit equation is different when you're giving away the
compiler vs. charging for it. It's often hard to say "no" to paying
customers.
The benefit
> side is questionable because in my observation, most codes of that
> vintage were written quite nonportably anyway. Most programmers of that
> era paid little attention to standards and portability. I'm quite sure
> there were notable exceptions, but my personal observation is that the
> majority of code of that era had little chance of surviving machine
> changes ithout significant porting work anyway. (I used to do a lot of
> thaty porting work; the scars prompted my later interest in standards.)
I agree there's probably litte benefit, but the cost doesn't seem to bad
either.
Terence
I have no regrets about losing the ASSIGNED GOTO statement.
Hut I still use the concept, by setting a variable to a number,
branching to a shared in-line code and returning from to the statement
following the line with the same assignment number through a computed
GOTO.
And this COMPUTED GOTO is interesting historically because the
implementation has usually been by a branch-through-index-table of
addresses; and this uses far less machine time for its one operation,
than sequentially testing for values (as in the current CASE concept),
at a time in history when machine cycle times were much more important.
Richard Harter
>In article <f9smck$tes$2...@aioe.org>, dpb <no...@non.net> wrote:
>
>> Richard Maine wrote:
>> ...
>> > If I recall skimming the error messages in the code in question, it
>> > provides an example. It has several things that are not portable. I'm
>> > not even sure I recognized some of them. (I'm a bit of a newbie and
>> > didn't start in Fortran until about 1967, though I did work with some
>> > pre-f66 compilers.)
>>
>> What other usenet group(s) would have a responder note they might be
>> considered a newbie having begun "only" in 1967? :)
>>
>> To paraphrase Jeff Foxworthy--"You might be a newbie if... " ? :)
>>
>> --
>
>You say 70-90 rather than 709-0.
No such thing - real programmers said seventy ninety.
>
>You started Fortran with version 4.
Just so. Newbies think that Fortran always had numbers after it.
>
>You think bytes are _always_ eight bits.
Characters have six bits except on decimal machines. What is a byte?
>
>You cannot write Fortran in _any_ language.
Now there's a competetion for you - what language is the hardest to
write fortran in?
>
>You never had 2 week turn around time.
Don't even go there.
As an addition:
You never put chad into a punched card to fix a bug.
Quadibloc
> If I recall skimming the error messages in the code in question, it
> provides an example. It has several things that are not portable.
Yes; one example is that the constants for converting from degrees to
radians, and radians to degrees, are initialized in internal System/
360 hexadecimal format, rather than letting the compiler convert from
decimal and lose the last bit of precision.
John Savard
Quadibloc
> Now there's a competetion for you - what language is the hardest to
> write fortran in?
C, Pascal and the like are easy enough.
Even Python will do in a pinch.
But it is pretty hard to write Fortran in LISP or Snobol.
John Savard
Quadibloc
> It seems to be OS/360 Fortran IV, except for the local modification
> to allow list directed I/O. OS/360 Fortran (and I believe successor
> compilers from IBM) allow $ as a letter in variable names. Some of the
> later errors are due to the compiler ignoring earlier statements with
> errors. Especially interesting is the message for missing END DO.
I believe I had it running on FORTRAN IV (level G).
The calls for device information, and the calls for plotting, are
local to the installation - which used the Michigan Terminal System.
John Savard
Peter Flass
> On Tue, 14 Aug 2007 13:22:42 -0400, Walter Bushell <pr...@oanix.com> wrote:
>
>>You cannot write Fortran in _any_ language.
>
>
> Now there's a competetion for you - what language is the hardest to
> write fortran in?
RPG?
robert....@sun.com
>
> >> It was "Structured Programming with the COMEFROM Statement".
> >> I had to explain that although it was not dated April, it was however,
> >> a well-written spoof on this mentioned article.
>
> > The Elxsi compiler in the mid 80's actually implemented the comefrom
> > statement (and several variants) as a continuation of this spoof. It
> > wasn't documented, but I found out about it when Ralph Merkle (one of
> > the developers) suggested that I might be amused by looking at a certain
> > area in the compiler executable file. When I did so, I found a list of
> > strings containing mostly familliar Fortran keywords. Amidst those, I
> > spotted comefrom. A quick check verified that the statement actually
> > compiled and worked as "expected".
>
> > I later heard that the statement was pulled from the compiler after a
> > customer submitted a bug report (I think it was a
> > performance/optimization issue) related to the comefrom statement
> > implementation. The joke wasn't worth actually investing scarce support
> > resources on.
I don't recall it being pulled.
> Were Computed and Assigned COMEFROM implemented, as well, or just an
> unconditional COMEFROM?
No. Only the conditional and unconditional COME FROM statements
were implemented.
Bob Corbett
Frank McCoy
A good candidate.
I submit: VTL-2 ... Though I *have* actually written a compiler in that
language.
--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
John Harper
How about Babylonian cuneiform? Ancient Egyptian hieroglyphics?
Turing machine code?
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
e p chandler
Was MTS Fortran the same as the IBM Fortran of the time?
Is there any MTS documentation on line? [memories of using $ME for e-
mail :-)]
Richard Steiner
glen herrmannsfeldt <g...@ugcs.caltech.edu> spake unto us, saying:
>> You think bytes are _always_ eight bits.
>
>No, but they should be.
Octets should be. Bytes tend to be different depending on context.
As a FIELDATA FORTRAN V programmer for a while (though more recently
than most), I tended to think in terms of six 6-bit bytes per 36-bit
word. These days it's four 9-bit bytes per 36-bit word. :-)
>> You cannot write Fortran in _any_ language.
>
>I will have to think about that one.
I dunno -- in BASIC, for example, it's easy:
10 PRINT "Fortran"
unless "write" implies file I/O...? ;-)
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA
Mainframe/Unix bit twiddler by day, OS/2+Linux+DOS hobbyist by night.
WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
The Theorem Theorem: If If, Then Then.
Richard Steiner
c...@tiac.net (Richard Harter) spake unto us, saying:
>On Tue, 14 Aug 2007 13:22:42 -0400, Walter Bushell <pr...@oanix.com>
>wrote:
>
>>You think bytes are _always_ eight bits.
>
>Characters have six bits except on decimal machines. What is a byte?
A Byte was a rather good magazine for it's time, though I have much
fonder memories of Creative Computing. :-)
Quadibloc
> Here in alt.folklore.computers,
> glen herrmannsfeldt <g...@ugcs.caltech.edu> spake unto us, saying:
> Octets should be. Bytes tend to be different depending on context.
>
> As a FIELDATA FORTRAN V programmer for a while (though more recently
> than most), I tended to think in terms of six 6-bit bytes per 36-bit
> word. These days it's four 9-bit bytes per 36-bit word. :-)
Characters might be 6 bits long, 8 bits long, or 16 bits long,
depending on whether you're talking about an old BCDIC machine, a
newer ASCII or EBCDIC machine, or one of those environments like Java
that uses Unicode.
Since "Byte" is an unusual new term, that many people encountered
first in connection with the IBM System/360, naturally, they took it
for a fixed unit of information.
Of course, if you go up the scale...
1 nybble = 4 bits
1 byte = 2 nybbles
1 halfword = 2 bytes
1 word = 2 halfwords
you do then conflict with a pre-established usage, since long before
the System/360, an IBM 7090 had a 36-bit word, and an Elliot 803 had a
39-bit word, and a PDP-1 had an 18-bit word.
However, the term "byte" actually did originate in contexts where it
could have a different size on different computer systems. But many
computer systems didn't use bytes at all. One packed two 6-bit
characters into a 12-bit word on a PDP-8; it didn't use "bytes"; these
were nowhere mentioned in its handbooks.
Thus, I thought Donald Knuth was being very peculiar when he used an
example computer in _The Art of Computer Programming_ that used a
"byte" that could be either 6 binary bits or 2 decimal digits (or, by
the rules given, four base-3 digits, as a "byte" must have at least 64
values, but may have no more than 100; so MIX could not be a base-7
machine, for example, nothing being available between 49 and 343).
But apparently users of such computers as the PDP-10 made the term
"byte" their own, and, in fact, the term "byte" had its start on the
bit-addressing STRETCH, which did use it for arbitrary-length strings
of bits. So to make everyone happy, the French had to fix things so
that an "octet" is no longer just a musical group of eight people.
John Savard
Steve O'Hara-Smith
> You say 70-90 rather than 709-0.
Hmm
> You started Fortran with version 4.
Yes - but I did learn II and the differences between II and IV.
> You think bytes are _always_ eight bits.
No - but I've never had to deal with other lengths.
> You cannot write Fortran in _any_ language.
Hmm - I might not be able to any more - it's been a long time.
> You never had 2 week turn around time.
No three days was my worst.
Conclusion - I might be a newbie. But then since my FORTRAN only
dates back to 1974 that was a given :)
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
Quadibloc
> Was MTS Fortran the same as the IBM Fortran of the time?
MTS Fortran WAS IBM Fortran. They bought a copy of the compiler from
IBM, and tweaked it to run under their different API. Software came
with source in those days, because computers were big, expensive
devices owned by trustworthy institutions, not cheap hobby machines
owned by... private individuals, whose activities were not so easily
monitored.
John Savard
Quadibloc
> How about Babylonian cuneiform? Ancient Egyptian hieroglyphics?
That might have been a problem once, but now, thanks to UNICODE,
adapting a Fortran compiler to use keywords taken from languages with
a non-Roman alphabet is essentially trivial.
John Savard
Terence
>> write fortran in?
Following John Harper's lead, I would suggest that the hardest KNOWN
language to write Fortran in, at least for which we have the symbols,
would be Linea "A".
That aside, I DO use Fortran to read and interpret, and write
(generate) source code for other programming languages as well as .RTF
and .HTM documents. I prefer it over other candiates for this work
like PL/1 and Pascal.
Peter Flass
That's an interesting project for someone with *way* too much time on
their hands. Download a cuneiform font...
jmfb...@aol.com
You could have added...you never had a 2 week turnaround time
to get a printout.
/BAH
jmfb...@aol.com
/BAH
jmfb...@aol.com
/BAH
Steve O'Hara-Smith
My mouse must be a Unix mouse ...
... it has no balls.
jmfb...@aol.com
Steve O'Hara-Smith <ste...@eircom.net> wrote:
>On Wed, 15 Aug 07 10:09:19 GMT
>jmfb...@aol.com wrote:
>
>> In article <f9smck$tes$2...@aioe.org>, dpb <no...@non.net> wrote:
>> >Richard Maine wrote:
>> >....
>> >> If I recall skimming the error messages in the code in question, it
>> >> provides an example. It has several things that are not portable. I'm
>> >> not even sure I recognized some of them. (I'm a bit of a newbie and
>> >> didn't start in Fortran until about 1967, though I did work with some
>> >> pre-f66 compilers.)
>> >
>> >What other usenet group(s) would have a responder note they might be
>> >considered a newbie having begun "only" in 1967? :)
>> >
>> >To paraphrase Jeff Foxworthy--"You might be a newbie if... " ? :)
>> >
>> you think a mouse has only one ball.
>
> My mouse must be a Unix mouse ...
>
>
>
> ... it has no balls.
>
ROTFL. Does it have a tail?
/BAH
Michael N. LeVine
Peter Flass <Peter...@Yahoo.com> wrote:
> Richard Maine wrote:
>
> > Peter Flass <Peter...@Yahoo.com> wrote:
> >
> >
> >>Walter Bushell wrote:
> >>
> >>
> >>>In article <46c0d2de$0$4663$4c36...@roadrunner.com>,
> >>> Peter Flass <Peter...@Yahoo.com> wrote:
<snip>
> >
> >
> > I think you ascribe other people's expressed attitudes to compiler
> > writers. There aren't actually very many currently supported compilers
> > that have direct roots back to the days when assigned GOTO was in the
> > language. It isn't a matter of "adding the code back in" to the
> > compiler. It is more a matter of putting it in in the first place. And
> > doing assigned GOTO in a way that conformed to the old standard has
> > "nontrivial" aspects on today's machines, where an address might well
> > not fit in a default integer. My second-hand understanding is that the
> > "usual" implementation trick involved shadow variables (I think that's
> > what they were called), where each integer variable used for an assigned
> > goto had two separate copies of different sizes - one for when it was
> > used as a statement label, and one for other uses.
>
> I think you're right. I'm reading this on a.f.c, not c.l.f. I'm not a
> FORTRAN guru, but IIRC the syntax was something like:
> go to a,10,20,30,40
actually it was
goto a,(10,20,30)
though the ",(10,20,30)" part of the syntax was optional
> ...
> assign 10 to a
> so I would expect that the assign also set the statement address as well
> as the value of a.
>
<snip>
--
Michael LeVine - mle...@redshift.com
"Thirty days hath September, April, June and November.
All the rest have thirty one except for Gypsy Rose Lee
and every one knew what she had" - Mel Blanc
Dave Seaman
I once did a programming assignment in which the assigned GOTO was
supposed to be used as a way to emulate coroutines. This involved doing
the ASSIGN to a variable in COMMON in one subroutine and later doing the
GOTO in a different subroutine
The compiler I was using (CDC's FTN) insisted on having a list of
possible targets for the GOTO. Of course, this made it necessary to lie
to the compiler because the actual destinations were not even in the same
program unit. Disabling optimization was a necessity (a fact of which we
were not warned by the instructor).
>> ...
>> assign 10 to a
>> so I would expect that the assign also set the statement address as well
>> as the value of a.
The variable a has only one value. It's just that its value happens to
be an address. This assumes, of course, that a Fortran INTEGER is big
enough to hold a machine address, which was generally true in computers
of the day.
--
Dave Seaman
Oral Arguments in Mumia Abu-Jamal Case heard May 17
U.S. Court of Appeals, Third Circuit
<http://www.abu-jamal-news.com/>
kkt
Stan Barr
Prolog... :-)
--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)
The future was never like this!
Steve O'Hara-Smith
jmfb...@aol.com wrote:
> In article <20070815141307....@eircom.net>,
> Steve O'Hara-Smith <ste...@eircom.net> wrote:
> >On Wed, 15 Aug 07 10:09:19 GMT
> >jmfb...@aol.com wrote:
> >
> >> In article <f9smck$tes$2...@aioe.org>, dpb <no...@non.net> wrote:
> >> >Richard Maine wrote:
> >> >....
> >> >> If I recall skimming the error messages in the code in question, it
> >> >> provides an example. It has several things that are not portable.
> >> >> I'm not even sure I recognized some of them. (I'm a bit of a newbie
> >> >> and didn't start in Fortran until about 1967, though I did work
> >> >> with some pre-f66 compilers.)
> >> >
> >> >What other usenet group(s) would have a responder note they might be
> >> >considered a newbie having begun "only" in 1967? :)
> >> >
> >> >To paraphrase Jeff Foxworthy--"You might be a newbie if... " ? :)
> >> >
> >> you think a mouse has only one ball.
> >
> > My mouse must be a Unix mouse ...
> >
> >
> >
> > ... it has no balls.
> >
>
> ROTFL. Does it have a tail?
Nope - it's a cordless optical mouse.
glen herrmannsfeldt
(snip)
> I once did a programming assignment in which the assigned GOTO was
> supposed to be used as a way to emulate coroutines. This involved doing
> the ASSIGN to a variable in COMMON in one subroutine and later doing the
> GOTO in a different subroutine
I am pretty sure that is illegal, though if it works and you
don't mind non-portability I suppose it is fine.
> The compiler I was using (CDC's FTN) insisted on having a list of
> possible targets for the GOTO. Of course, this made it necessary to lie
> to the compiler because the actual destinations were not even in the same
> program unit. Disabling optimization was a necessity (a fact of which we
> were not warned by the instructor).
PL/I, which does allow GOTO to LABEL variables between routines, only
allows them back into the call tree. I believe that is also true for
longjmp() in C.
-- glen
ArarghMai...@not.at.arargh.com
Steiner) wrote:
>Here in alt.folklore.computers,
>glen herrmannsfeldt <g...@ugcs.caltech.edu> spake unto us, saying:
>
>>> You think bytes are _always_ eight bits.
>>
>>No, but they should be.
>
>Octets should be. Bytes tend to be different depending on context.
>
>As a FIELDATA FORTRAN V programmer for a while (though more recently
>than most), I tended to think in terms of six 6-bit bytes per 36-bit
>word. These days it's four 9-bit bytes per 36-bit word. :-)
>
>>> You cannot write Fortran in _any_ language.
>>
>>I will have to think about that one.
>
>I dunno -- in BASIC, for example, it's easy:
>
> 10 PRINT "Fortran"
>
>unless "write" implies file I/O...? ;-)
In that case:
10 LPRINT "Fortran"
writes to the printer.
--
ArarghMail708 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
ArarghMai...@not.at.arargh.com
wrote:
Why would they have had to buy it? If they were using a 360, the OS &
source was available for free, IIRC. Still is, actually. I have
downloaded a copy. Unless the version of Fortran being used was a
Program Product?
Dave Seaman
> Dave Seaman wrote:
> (snip)
>> I once did a programming assignment in which the assigned GOTO was
>> supposed to be used as a way to emulate coroutines. This involved doing
>> the ASSIGN to a variable in COMMON in one subroutine and later doing the
>> GOTO in a different subroutine
> I am pretty sure that is illegal, though if it works and you
> don't mind non-portability I suppose it is fine.
I agree that it's illegal, and that was understood when I got the assignment.
But I got it to work.
>> The compiler I was using (CDC's FTN) insisted on having a list of
>> possible targets for the GOTO. Of course, this made it necessary to lie
>> to the compiler because the actual destinations were not even in the same
>> program unit. Disabling optimization was a necessity (a fact of which we
>> were not warned by the instructor).
> PL/I, which does allow GOTO to LABEL variables between routines, only
> allows them back into the call tree. I believe that is also true for
> longjmp() in C.
> -- glen
--
krw
625.area1.spcsdns.net>, pr...@oanix.com says...
> In article <f9smck$tes$2...@aioe.org>, dpb <no...@non.net> wrote:
>
> > Richard Maine wrote:
> > ...
> > > provides an example. It has several things that are not portable. I'm
> > > not even sure I recognized some of them. (I'm a bit of a newbie and
> > > didn't start in Fortran until about 1967, though I did work with some
> > > pre-f66 compilers.)
> >
> > What other usenet group(s) would have a responder note they might be
> > considered a newbie having begun "only" in 1967? :)
> >
> > To paraphrase Jeff Foxworthy--"You might be a newbie if... " ? :)
> >
>
> You say 70-90 rather than 709-0.
Haven't heard "709-0", but have heard "7-oh-90" and "7-oh-94".
> You started Fortran with version 4.
I did, but the Bendix G-20s used ForTran II.
> You think bytes are _always_ eight bits.
Nope.
> You cannot write Fortran in _any_ language.
I can't in VHDL.
> You never had 2 week turn around time.
Nope. Even in '68 I never had to wait longer than over-night;
usually no longer than an hour or so.
--
Keith
Dave Seaman
> In article <proto-E6AD8A.13224214082007@032-325-
> 625.area1.spcsdns.net>, pr...@oanix.com says...
>> In article <f9smck$tes$2...@aioe.org>, dpb <no...@non.net> wrote:
>>
>> > Richard Maine wrote:
>> > ...
>> > > If I recall skimming the error messages in the code in question, it
>> > > provides an example. It has several things that are not portable. I'm
>> > > not even sure I recognized some of them. (I'm a bit of a newbie and
>> > > didn't start in Fortran until about 1967, though I did work with some
>> > > pre-f66 compilers.)
>> >
>> > What other usenet group(s) would have a responder note they might be
>> > considered a newbie having begun "only" in 1967? :)
>> >
>> > To paraphrase Jeff Foxworthy--"You might be a newbie if... " ? :)
>> >
>> > --
>>
>> You say 70-90 rather than 709-0.
> Haven't heard "709-0", but have heard "7-oh-90" and "7-oh-94".
There was once a 709T (seven-oh-nine-tee), which was evidently a
transistorized 709. At least I think that's how I heard it explained by
Saul Rosen.
Peter Flass
Has to, because anything else has had its stack frame popped.
Walter Bushell
c...@tiac.net (Richard Harter) wrote:
> On Tue, 14 Aug 2007 13:22:42 -0400, Walter Bushell <pr...@oanix.com> wrote:
>
> >In article <f9smck$tes$2...@aioe.org>, dpb <no...@non.net> wrote:
> >
> >> Richard Maine wrote:
> >> ...
> >> > If I recall skimming the error messages in the code in question, it
> >> > provides an example. It has several things that are not portable. I'm
> >> > not even sure I recognized some of them. (I'm a bit of a newbie and
> >> > didn't start in Fortran until about 1967, though I did work with some
> >> > pre-f66 compilers.)
> >>
> >> What other usenet group(s) would have a responder note they might be
> >> considered a newbie having begun "only" in 1967? :)
> >>
> >> To paraphrase Jeff Foxworthy--"You might be a newbie if... " ? :)
> >>
> >> --
> >
> >You say 70-90 rather than 709-0.
>
> No such thing - real programmers said seventy ninety.
> >
> >You started Fortran with version 4.
>
> Just so. Newbies think that Fortran always had numbers after it.
> >
> >You think bytes are _always_ eight bits.
>
> Characters have six bits except on decimal machines. What is a byte?
>
> >
> >You cannot write Fortran in _any_ language.
>
> Now there's a competetion for you - what language is the hardest to
> write fortran in?
>
> >
> >You never had 2 week turn around time.
>
> Don't even go there.
>
> As an addition:
>
> You never put chad into a punched card to fix a bug.
Not the people who worked with the 709.
Walter Bushell
Frank McCoy <mcc...@millcomm.com> wrote:
> In alt.folklore.computers Peter Flass <Peter...@Yahoo.com> wrote:
>
> >Richard Harter wrote:
> >
> >> On Tue, 14 Aug 2007 13:22:42 -0400, Walter Bushell <pr...@oanix.com> wrote:
> >>
> >>>You cannot write Fortran in _any_ language.
> >>
> >>
> >> Now there's a competetion for you - what language is the hardest to
> >> write fortran in?
> >
> >RPG?
>
> A good candidate.
> I submit: VTL-2 ... Though I *have* actually written a compiler in that
> language.
INTERCAL?
Roland Hutchinson
> Now there's a competetion for you - what language is the hardest to
> write fortran in?
For the sake of symmetry, we should also ask what language is the easiest to
write Fortran in.
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam. If your message looks like spam I may not see it.
Roland Hutchinson
> In article <1187134373....@x35g2000prf.googlegroups.com>,
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>>Richard Harter wrote:
>>> Now there's a competetion for you - what language is the hardest to
>>> write fortran in?
>>
>>C, Pascal and the like are easy enough.
>>Even Python will do in a pinch.
>>But it is pretty hard to write Fortran in LISP or Snobol.
>
> How about Babylonian cuneiform?
No, you want the competition for what language is hardest to write
washing-bills in.
Quadibloc
> For the sake of symmetry, we should also ask what language is the easiest to
> write Fortran in.
In order to avoid asking a question with an obvious answer, we would
have to change the question to "what language, other than Fortran, is
the easiest...", which spoils the symmetry.
Of course, I suppose we could add the same qualifier to the "hardest"
question without harm...
John Savard
David Jones
>
> Now there's a competetion for you - what language is the hardest to
> write fortran in?
>
http://www.kaleberg.com/misc/flatscreen.html
(unfortunately I can't find a better citation)
David Jones
David Powell
Quadibloc <jsa...@ecn.ab.ca> in alt.folklore.computers wrote:
>Richard Steiner wrote:
>> Here in alt.folklore.computers,
>> glen herrmannsfeldt <g...@ugcs.caltech.edu> spake unto us, saying:
>
>> Octets should be. Bytes tend to be different depending on context.
>>
>> As a FIELDATA FORTRAN V programmer for a while (though more recently
>> than most), I tended to think in terms of six 6-bit bytes per 36-bit
>> word. These days it's four 9-bit bytes per 36-bit word. :-)
>
>Characters might be 6 bits long, 8 bits long, or 16 bits long,
>depending on whether you're talking about an old BCDIC machine, a
>newer ASCII or EBCDIC machine, or one of those environments like Java
>that uses Unicode.
>
>Since "Byte" is an unusual new term, that many people encountered
>first in connection with the IBM System/360, naturally, they took it
>for a fixed unit of information.
>
>Of course, if you go up the scale...
>
>1 nybble = 4 bits
>1 byte = 2 nybbles
>1 halfword = 2 bytes
>1 word = 2 halfwords
>
>you do then conflict with a pre-established usage, since long before
>the System/360, an IBM 7090 had a 36-bit word, and an Elliot 803 had a
>39-bit word, and a PDP-1 had an 18-bit word.
>
>However, the term "byte" actually did originate in contexts where it
>could have a different size on different computer systems. But many
>computer systems didn't use bytes at all. One packed two 6-bit
>characters into a 12-bit word on a PDP-8; it didn't use "bytes"; these
>were nowhere mentioned in its handbooks.
>
For about 5 years until the introduction of the Omnibus machines which
have the ByteSWap instruction.
Regards,
David P.
Dave Seaman
> In article <1187154265.4...@q3g2000prf.googlegroups.com>,
> Quadibloc <jsa...@ecn.ab.ca> in alt.folklore.computers wrote:
>>Richard Steiner wrote:
>>> Here in alt.folklore.computers,
>>> glen herrmannsfeldt <g...@ugcs.caltech.edu> spake unto us, saying:
>>
>>> Octets should be. Bytes tend to be different depending on context.
>>>
>>> As a FIELDATA FORTRAN V programmer for a while (though more recently
>>> than most), I tended to think in terms of six 6-bit bytes per 36-bit
>>> word. These days it's four 9-bit bytes per 36-bit word. :-)
>>
>>Characters might be 6 bits long, 8 bits long, or 16 bits long,
>>depending on whether you're talking about an old BCDIC machine, a
>>newer ASCII or EBCDIC machine, or one of those environments like Java
>>that uses Unicode.
>>
>>Since "Byte" is an unusual new term, that many people encountered
>>first in connection with the IBM System/360, naturally, they took it
>>for a fixed unit of information.
>>
>>Of course, if you go up the scale...
>>
>>1 nybble = 4 bits
>>1 byte = 2 nybbles
>>1 halfword = 2 bytes
>>1 word = 2 halfwords
The following terminology comes from the CDC Cyber 205:
1 word = 8 bytes = 64 bits
1 sword = 1 superword = 8 words
1 pen = 2 swords = 16 words (well, it's mightier, you see)
James Raynard
> I find it odd that no one has mentioned French Fortran (ie with =
>keywords in French): for those who don't believe such a thing existed, =
>see for example
>http://www.kaleberg.com/misc/flatscreen.html
>(unfortunately I can't find a better citation)
Googling on "Fortran francais" turned up the following (apologies for
any translation errors):
"The biggest machine of the time - almost - was the IBM704. There were
hundreds of these in the USA, but only one in France. This had been
displayed for some time in a glass case in the Place Vendome and performed
various services. It had rudimentary software, in particular French software;
it even had French Fortran, thanks to the incredible skill of Persuis
and Guerin (you try replacing GOTO with ALLER A in a tangled forest of code
where the key words are stored in the unused fields of instructions)."
This comes from an interesting-looking lecture in which one of the "midwives"
reminisces (in French, sorry) about the birth of French academic computing
in the 1950s.
http://www.ehess.fr/revue-msh/pdf/N141R776.pdf
James
John Harper
Quadibloc <jsa...@ecn.ab.ca> wrote:
>John Harper wrote:
>> How about Babylonian cuneiform? Ancient Egyptian hieroglyphics?
>
>That might have been a problem once, but now, thanks to UNICODE,
>adapting a Fortran compiler to use keywords taken from languages with
>a non-Roman alphabet is essentially trivial.
>
>John Savard
>
That reminds me: many years ago we bought a machine with a French
Algol 60 compiler. Before it arrived we all wondered how polite the
French had to be to their computers: would BEGIN turn into COMMENCE
or COMMENCEZ ? It turned out to be COMMENCER .
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Terence
A byte was introduced as a word to mean "the smallest addressable
element in computer memory".
It didn't imply eight bits even if that was the most common at the
time; it REALLY was associated with "taking a bite". And the joke was
prolonged with the later term "nibble".
The French Fortran is possible associated with te legal requirement
formally introduced in France and more severely in Quebec Canada for
"equal-or-more-so" use and display of French over English usage, at a
time whn French die-hards saw the original imperitive use of Frence in
society and especially Diplomacy, began to die away in favor of the
complex, difficult-to-spell English (but which happened, with Spanish,
to be one of the two most rich langauges for word numbers and nuance).
I've seen French Fortan and normal Fortran otherwise in French. French
programmers were once very well established in animation and display
which is rich in mathematical operations.
Lastly, the earliest Fortran compilers I worked with in the beginning
of the 60's at IBM were the 704 and 1401 versions, with, of course,
weirdly wonderful word bit sizes, parity and storage arrangements.
Walter Bushell
har...@mcs.vuw.ac.nz (John Harper) wrote:
Having only high school French, where we spent two weeks leaning to say
"hello" etc. , before the teacher broke down and told use what we were
saying.
Quadibloc
> The following terminology comes from the CDC Cyber 205:
> 1 word = 8 bytes = 64 bits
> 1 sword = 1 superword = 8 words
> 1 pen = 2 swords = 16 words (well, it's mightier, you see)
It must have been a particularly dark and stormy night when somebody
thought that up!
John Savard
Roland Hutchinson
> That reminds me: many years ago we bought a machine with a French
> Algol 60 compiler. Before it arrived we all wondered how polite the
> French had to be to their computers: would BEGIN turn into COMMENCE
> or COMMENCEZ ? It turned out to be COMMENCER .
And why not? It seems somehow appropriate (in a nerdish-punning-amusement
sort of way) to address the computer with the IMPERSONAL imperative (i.e.,
the infinitive), given that the machine is not a person.
By the way, in case you didn't know, French cookbooks (actual cookbooks, for
cooking food) use the same infinitive-as-impersonal-imperative convention
in setting out recipes.
Roland Hutchinson
I think we may have a winner.
INTERCAL is just plain the hardest language to write _anything_ in.
It is therefore, _a fortiori_, the hardest language to write FORTRAN in.
Michael Widerkrantz
> INTERCAL is just plain the hardest language to write _anything_ in.
INTERCAL is hard, yes, but what about Brainfuck, Unlambda, Orthogonal
or Whitespace?
I have only tried programming anything in INTERCAL, but Unlambda made
me shiver when I looked at the documentation some time ago. Consider,
for example:
```s``sii`ki
``s``s`ks
``s``s`ks``s`k`s`kr
``s`k`si``s`k`s`k
`d````````````.H.e.l.l.o.,. .w.o.r.l.d.!
k
k
`k``s``s`ksk`k.*
jmfb...@aol.com
Honey, do you see that funny shaped key with an arrow glyph and the
word Enter on it? Please use it.
>Richard Harter wrote:
>>
>> Now there's a competetion for you - what language is the hardest to
>> write fortran in?
>>
> I find it odd that no one has mentioned French Fortran
Now go look for the official COBOL keywords. I'll bet they
made a FRench COBOL, too.
>(ie with keywords in French): for those who don't believe
>such a thing existed, see for example
>http://www.kaleberg.com/misc/flatscreen.html
>(unfortunately I can't find a better citation)
/BAH
jmfb...@aol.com
Quadibloc <jsa...@ecn.ab.ca> wrote:
>Dave Seaman wrote:
>> The following terminology comes from the CDC Cyber 205:
>> 1 word = 8 bytes = 64 bits
>> 1 sword = 1 superword = 8 words
>> 1 pen = 2 swords = 16 words (well, it's mightier, you see)
>It must have been a particularly dark and stormy night when somebody
>thought that up!
Or they had just fixed the thorniest bug of all and had to goof off
to let the steam out.
/BAH
jmfb...@aol.com
You are kidding. Nobody could be that perverse and expect to be
taken seriously. I couldn't check even one line for typos.
/BAH
Quadibloc
> In article <1187310240.3...@q4g2000prc.googlegroups.com>,
> Quadibloc <jsa...@ecn.ab.ca> wrote:
> >Dave Seaman wrote:
> >> The following terminology comes from the CDC Cyber 205:
.
> >> 1 sword = 1 superword = 8 words
> >> 1 pen = 2 swords = 16 words (well, it's mightier, you see)
.
> >thought that up!
> Or they had just fixed the thorniest bug of all and had to goof off
> to let the steam out.
That is possible too.
However, my comment was a veiled reference to the *source* of the
famous quote...
Under the rule of men entirely great, the pen is mightier than the
sword.
- Edward Bulwer-Lytton, _Richelieu, or The Conspiracy_
It was a dark and stormy night; the rain fell in torrents - except at
occasional intervals, when it was checked by a violent gust of wind
which swept up the streets (for it is in London that our scene lies),
rattling along the housetops, and fiercely agitating the scanty flame
of the lamps that struggled against the darkness.
- Edward Bulwer-Lytton, _Paul Clifford_
Of course, since Euripides wrote "The tongue is mightier than the
blade", Bulwer-Lytton might fairly be said to have been paraphrasing
Euripides here.
John Savard
Quadibloc
> You are kidding. Nobody could be that perverse and expect to be
> taken seriously. I couldn't check even one line for typos.
The people designing *those* languages did not *expect* to be taken
seriously; although full definitions are given for those languages -
and implementations - they are intended as jokes.
John Savard
Quadibloc
> John Harper wrote:
.
> > That reminds me: many years ago we bought a machine with a French
> > Algol 60 compiler. Before it arrived we all wondered how polite the
> > French had to be to their computers: would BEGIN turn into COMMENCE
> > or COMMENCEZ ? It turned out to be COMMENCER .
.
> And why not? It seems somehow appropriate (in a nerdish-punning-amusement
> sort of way) to address the computer with the IMPERSONAL imperative (i.e.,
> the infinitive), given that the machine is not a person.
.
> By the way, in case you didn't know, French cookbooks (actual cookbooks, for
> cooking food) use the same infinitive-as-impersonal-imperative convention
> in setting out recipes.
That I did not know. However, a cookbook sets out a plan of making a
dish, which the reader may or may not execute as he - or she - sees
fit. One does not read a cookbook from beginning to end, cooking
everything in it when commanded.
So a cookbook is not *giving orders* to its reader.
It would seem to me, therefore, that use of the imperative - the
familiar imperative rather than the polite - is appropriate for a
computer program, because there one is giving orders to the computer
that it is to obey upon receipt. (Or would the infinitive be
appropriate if the language is compiled instead of interpreted?)
And, of course, what does French pseudocode look like?
John Savard
Quadibloc
> Now go look for the official COBOL keywords. I'll bet they
> made a FRench COBOL, too.
Given the *purpose* of COBOL's verbose style, it would be a very
reasonable thing to do.
More reasonable, though, would be a French BASIC - and, indeed,
versions of BASIC in all sorts of different languages.
After all, would the personal computer revolution in the U.S. have
taken the same form if the computers with BASIC all used Latin - or
French, or German - keywords? Using English keywords made BASIC much
easier for beginners in computing to learn.
There *was* a Russian-language dialect of ALGOL; I remember seeing
that described in a book about one of their computers. And I believe
there definitely was a French ALGOL as well.
It's even possible the ALGOL 60 standard even made specific provision
for different-language keywords as one of the allowable differences
between a "hardware representation" and the "publication
language" (this distinction being the reason people don't need to type
in Pascal programs using boldface for the keywords, and italic for the
variables, using normal type only for the comments).
John Savard
jmfb...@aol.com
Quadibloc <jsa...@ecn.ab.ca> wrote:
>jmfbah...@aol.com wrote:
>> Now go look for the official COBOL keywords. I'll bet they
>> made a FRench COBOL, too.
>Given the *purpose* of COBOL's verbose style, it would be a very
>reasonable thing to do.
It is a state edict to purge all non-French words from all aspects
of French life. They're idiots to handcuff their people and innovations.
>
>More reasonable, though, would be a French BASIC - and, indeed,
>versions of BASIC in all sorts of different languages.
I don't know. I watched about 40 kids in China program in BASIC
using the English version. Those kids will be able to code
anywhere in the world because the associated certain glyphs
with basic computing concepts. That's what an HLL should do
in the computing biz; not breed social arrogance.
>
>After all, would the personal computer revolution in the U.S. have
>taken the same form if the computers with BASIC all used Latin - or
>French, or German - keywords?
No.
> Using English keywords made BASIC much
>easier for beginners in computing to learn.
Using English allowed us to create new words to explain new concepts.
No other language would have been able to do that.
English is wonderfully sloppy and allows anybody to create any word
they want.
>
>There *was* a Russian-language dialect of ALGOL; I remember seeing
>that described in a book about one of their computers. And I believe
>there definitely was a French ALGOL as well.
I have three books about computers in Russian. They didn't use
their alphabet in these compilers.
>
>It's even possible the ALGOL 60 standard even made specific provision
>for different-language keywords as one of the allowable differences
>between a "hardware representation" and the "publication
>language" (this distinction being the reason people don't need to type
>in Pascal programs using boldface for the keywords, and italic for the
>variables, using normal type only for the comments).
/BAH
Richard F. Drushel
: More reasonable, though, would be a French BASIC - and, indeed,
: versions of BASIC in all sorts of different languages.
There is a French version of SmartBASIC 1.0 for the Coleco ADAM.
Also French *AND* German versions of the ROM SmartWriter word processor.
The latter were supplied on a center-slot expansion card that the boot code
looked for before running the motherboard ROM version (English). However,
only ADAMs built for the European market had the 3 magic decoder lines
run out to the center slot for those cards to work. I have an ADAM in
which I swapped out the English ROMs for the French ROMs. I can't remember
if I had to desolder the French ROMs from the card or not. The stuff is
packed away...
Followups set to alt.folklore.computers only.
*Rich*
--
Richard F. Drushel, Ph.D. | "They fell: for Heaven to them no hope
Instructor and Executive Officer | imparts / Who hear not for the beating
Department of Biology, CWRU | of their hearts."
Cleveland, Ohio 44106-7080 U.S.A. | -- Edgar Allan Poe, "Al-Aaraaf"
Gordon Sande
In the case of Algol 60 there was problem with keywords. Many
teleprinters of the day had an ability to print in either red or
black with a two colored ribbon. Keywords in red and nonkeywords
in black. The paper tape controls were for a "shift in" or "shift
out" for the two halves of the ribbon. For cards with only capitals
the keywords were marked with single quotes while strings used double
quotes. Algol 60 was a nice language but keying it on cards was a bit
of a bother.
Roland Hutchinson
> Roland Hutchinson wrote:
>> For the sake of symmetry, we should also ask what language is the easiest
>> to write Fortran in.
> .
> In order to avoid asking a question with an obvious answer, we would
> have to change the question to "what language, other than Fortran, is
> the easiest...", which spoils the symmetry.
Absolutely not! The question of whether any dialect of Fortran is actually
the easiest language in which to "write Fortran" (in the sense intended in
the old saying about being able to do it in any language) is precisely the
point that ought to be considered.
It is, for example, conceivable that some dialect of BASIC might be the
easiest in which to "write Fortran" in that sense.
> Of course, I suppose we could add the same qualifier to the "hardest"
> question without harm...
But again, that would prematurely exclude the possibility that the hardest
language to write Fortran in might, in fact, be Fortran. (As an aside,
though perhaps not a totally irrelevant one, note that Fortran II is
certainly _a_ difficult language in which to write Fortran 2003.)
Christopher C. Stacy
> There *was* a Russian-language dialect of ALGOL; I remember seeing
> that described in a book about one of their computers.
In Russia, labels GOTO *you*!
Roland Hutchinson
> Roland Hutchinson wrote:
>> John Harper wrote:
> .
>> > That reminds me: many years ago we bought a machine with a French
>> > Algol 60 compiler. Before it arrived we all wondered how polite the
>> > French had to be to their computers: would BEGIN turn into COMMENCE
>> > or COMMENCEZ ? It turned out to be COMMENCER .
> .
>> And why not? It seems somehow appropriate (in a
>> nerdish-punning-amusement sort of way) to address the computer with the
>> IMPERSONAL imperative (i.e., the infinitive), given that the machine is
>> not a person.
> .
>> By the way, in case you didn't know, French cookbooks (actual cookbooks,
>> for cooking food) use the same infinitive-as-impersonal-imperative
>> convention in setting out recipes.
> .
> That I did not know.
For your further information, German does the same. Actually, a lot of
languages do.
> However, a cookbook sets out a plan of making a
> dish, which the reader may or may not execute as he - or she - sees
> fit. One does not read a cookbook from beginning to end, cooking
> everything in it when commanded.
>
> So a cookbook is not *giving orders* to its reader.
Rather, it is -- as instructors in beginning programming classes have been
pointing out for decades -- expressing an algorithm. So in that respect it
is quite like a program (at least if you are a mathematician).
Roland Hutchinson
> In article <1187358367.2...@i38g2000prf.googlegroups.com>,
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>> Using English keywords made BASIC much
>>easier for beginners in computing to learn.
>
> Using English allowed us to create new words to explain new concepts.
> No other language would have been able to do that.
You REALLY need to get out more, Barb.
Roland Hutchinson
That accounts for INTERCAL, Brainfuck, Unlambda, Orthogonal, and
Whitespace, but how do you explain TECO?
Terence
> hundreds of these in the USA, but only one in France. This had been
> displayed for some time in a glass case in the Place Vendome and performed
> various services. It had rudimentary software, in particular French software;
> it even had French Fortran, thanks to the incredible skill of Persuis
> and Guerin (you try replacing GOTO with ALLER A in a tangled forest of code
> where the key words are stored in the unused fields of instructions)."
I actually worked in the IBM Place Vendome offices in 1962, Paris,
prior to more work at the IBM La Goude labs near Nice in 1963! I also
attended a course there on solving simultaneous linear equations and
equalities and optimisation methods, before working on kernel methods
for implementing searching convex surfaces for extreme apexes, for
optimization software for the new IBM 360. I think the first use was
ingredient selection for sausage manufacture!
Quadibloc
> It is, for example, conceivable that some dialect of BASIC might be the
> easiest in which to "write Fortran" in that sense.
Perhaps second easiest.
PL/I would almost certainly take top honors IMO.
John Savard