Why did they make FORTRAN so hard to parse? 
Author Message
 Why did they make FORTRAN so hard to parse?

Quote:

>There were a tad annoying with just plain TECO, too.  VT50s
>had 12 lines.  I would have trashed the damned thing if it
>hadn't had a flat top.  Going from a VT05 to a VT50 had
>one advantage--cup and listing shelf without a slope.

Thank you!  I used those <censored> things back in the mid-70s, and
I always wondered if there was *anything* good one could say about
them.

The management of my PPOE was suckered into buying far too many VT50s
as part of a deal to get a KL10.  To the best of my knowledge, management
never discussed the selection with either the computer center or any
of the faculty.

Joe Morris



Thu, 07 Jul 2005 00:42:32 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:



>>>I think the 2265/2845 single-screen/controller combo was 12*80 only.
>>Now I think of it, I believe it also had a 2260-incompatible mode,
>>something like 15*64.
> Well, now, fancy meeting you here. What else do you do besides B5 and
> Shakespeare? :)

Sing, arrange music, and handle the website for the Orpheus Club of
Newark (http://orpheus_club_newark.tripod.com).

Sing with the Lubo Opera Company.

Act, compose music, maintain part of the website, and novelize past
years at the New Jersey Renaissance Kingdom (http://www.NJKingdom.com).
  (But I gotta tell you, 54 is _much_ too old to be starting broadsword
lessons!)

I'm working on porting the software for The Loglan Institute
(http://www.loglan.org) to Java, and translating "The Wizard of Oz" into
Loglan.

Some day I'll finish coding "Glastonbury Tor", an interactive-fiction
game my wife designed.

And I'm an active member of the International Wizard of Oz Club.

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Thu, 07 Jul 2005 04:44:22 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:

>>IBM used something horrid along these lines:

>>     'BEGIN' 'REAL' X., 'INTEGER' I, J., 'REAL''ARRAY' A(/0..9, 0..9/).,
>>        ...
>>        X .= A(/I, J/).,
>>        ...
>>        OUTSTRING ('('HELLO WORLD')').,
>>        ...
>>     'END'
> Used by some other manufacturers too, not having heard of ASCII.

Even ASCII doesn't have left and right quotes -- or boldface.  And most
60's printers not made by IBM were drum printers, which encourage a
minimal character set.  (Chain/train/band printers slow down with a
larger character set, but can be changed.  The character set of a drum
printer is fixed.)

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"



Thu, 07 Jul 2005 04:44:27 GMT  
 Why did they make FORTRAN so hard to parse?
Quote:

>>>wb4alm?  olden days?  Is old  before '80, '70,  '60, '50, '40, or earlier?

>Yes. ;-)

Whooo,  I just squeeked by on that one. You had me worried for a minute.
I actually thought I was getting old.

Quote:
>I spent too many years looking at UPPER CASE ALL THE TIME, so I use lower
>case whenever I can...  :-)

>Ah, but life was so much more simple in uppercase.

Yeah, the manners were better - it was much harder to shout!

Quote:
>There were a tad annoying with just plain TECO, too.  VT50s
>had 12 lines.  I would have trashed the damned thing if it
>hadn't had a flat top.  Going from a VT05 to a VT50 had
>one advantage--cup and listing shelf without a slope.

I used a beanbag cup with a lid, could perch it on the edge...

Quote:
>Do a complete anti-cap and you get bill turner, wb4alm.

>Now how would a dood interpret that?

Some of my students couldn't get pass the "b". I think they got stressed
out when trying to remember
that they were trying to learn their ABC's. The only C'ing they did was
viewing the opposite gender.

/s/ bill turner, wb4alm

Quote:

>/BAH

>Subtract a hundred and four for e-mail.



Thu, 07 Jul 2005 05:30:29 GMT  
 Why did they make FORTRAN so hard to parse?

...

Quote:
> As far as the recursion and variable-sized local arrays are concerned,
> well, you know about fortran 90 and probably C90 - and I can assure
> you that the arguments used against them in C90 were the same ones as
> were used against Algol 60 by the "IBM camp" ....

IBM had nothing against either recursion or variable-sized local arrays.  PL/I
has both.

There have been several references in this discussion to the phrase
"variable-sized local array" in the context of a "controversy" concerning Algol
60.  I believe the "controversy" being referred to is actually the problem
surrounding the implementation of the dynamic OWN array in Algol 60.  Here
dynamic is synonymous with variable-sized and OWN is equivalent to PL/I's STATIC.
The problem is that it was necessary to introduce a method whereby a subroutine
or function could retain information between calls.  This occurs naturalli in
FORTRAN, since the local storage belonging to a subroutine or function is
statically allocated.  In Algol 60 all variables are allocated upon block entry
and deallocated upon bloce exit.  To allow routines to retain the values of
selected local variables between calls, the designers of Algol 60 introduced the
variable attribute OWN.  Only later was it realized that this has rather far
reaching implications in the case of local dynamic arrays.  That is what became
the topic of debate for at least 20 or 30 years.  It may well still be going on.

For example, suppose a procedure p contains the declaration

   OWN REAL ARRAY a(l,m)

where l and m are parameters of p.

Suppose further that p is called with l=3 and m=7.  During this invocation
values are assigned to all the elements of a.

Now suppose p is called a second time with l=10 and m=4.  What is to happen to
the values in the subarray a(1..3,5..7) of the original a?  During this
invocation all elements are eventually assigned values, some of them presumably
depending on the values of array elements that had been assigned during the
first call. What about the new elements that did not previously exist? The
language specification was silent on these questions.

Finally, suppose p is called a third time with l=6 and m=14.  Should the
subarray that "disappeared" during the second invocation reappear?  (I would say
it would have to for the concept to make any sense, but this, and a host of
other questions, is what the debate was all about.  Actually, it isn't all that
hard to see how it could be implemented, but it is inefficient and messy.

PL/I legislates the problem out of existence by requiring that static arrays,
strings, and areas have constant bounds, lengths, and sizes.



Thu, 07 Jul 2005 13:37:01 GMT  
 Why did they make FORTRAN so hard to parse?



(snip)

Quote:

> There have been several references in this discussion to the
phrase
> "variable-sized local array" in the context of a "controversy"
concerning Algol
> 60.  I believe the "controversy" being referred to is actually
the problem
> surrounding the implementation of the dynamic OWN array in Algol
60.  Here
> dynamic is synonymous with variable-sized and OWN is equivalent
to PL/I's STATIC.
> The problem is that it was necessary to introduce a method

whereby a subroutine
Quote:
> or function could retain information between calls.  This occurs
naturalli in
> FORTRAN, since the local storage belonging to a subroutine or
function is
> statically allocated.  In Algol 60 all variables are allocated
upon block entry
> and deallocated upon bloce exit.  To allow routines to retain the
values of
> selected local variables between calls, the designers of Algol 60
introduced the
> variable attribute OWN.  Only later was it realized that this has
rather far
> reaching implications in the case of local dynamic arrays.  That
is what became
> the topic of debate for at least 20 or 30 years.  It may well
still be going on.

> For example, suppose a procedure p contains the declaration

>    OWN REAL ARRAY a(l,m)

> where l and m are parameters of p.

> Suppose further that p is called with l=3 and m=7.  During this
invocation
> values are assigned to all the elements of a.

> Now suppose p is called a second time with l=10 and m=4.  What is
to happen to
> the values in the subarray a(1..3,5..7) of the original a?
During this
> invocation all elements are eventually assigned values, some of
them presumably
> depending on the values of array elements that had been assigned
during the
> first call. What about the new elements that did not previously
exist? The
> language specification was silent on these questions.

> Finally, suppose p is called a third time with l=6 and m=14.
Should the
> subarray that "disappeared" during the second invocation

reappear?  (I would say

Quote:
> it would have to for the concept to make any sense, but this, and
a host of
> other questions, is what the debate was all about.  Actually, it
isn't all that
> hard to see how it could be implemented, but it is inefficient
and messy.

> PL/I legislates the problem out of existence by requiring that
static arrays,
> strings, and areas have constant bounds, lengths, and sizes.

Well, I would say that CONTROLLED instead of STATIC would work
better for this problem.  The program itself, (using a STATIC flag)
allocates the memory to the desired size when the size is known,
and frees/reallocates it to a new size when needed.

-- glen



Thu, 07 Jul 2005 17:10:44 GMT  
 Why did they make FORTRAN so hard to parse?


Quote:

>> As far as the recursion and variable-sized local arrays are concerned,
>> well, you know about Fortran 90 and probably C90 - and I can assure
>> you that the arguments used against them in C90 were the same ones as
>> were used against Algol 60 by the "IBM camp" ....

>IBM had nothing against either recursion or variable-sized local arrays.  PL/I
>has both.

Sorry, but you are mistaken.  I was closely associated with the IBM
compiler teams for many years and have worked in Santa Teresa.  Yes,
PL/I had them, but PL/I was a bit oddball in many respects (and see
below).

Quote:
>There have been several references in this discussion to the phrase
>"variable-sized local array" in the context of a "controversy" concerning Algol
>60.  I believe the "controversy" being referred to is actually the problem
>surrounding the implementation of the dynamic OWN array in Algol 60.  Here
>dynamic is synonymous with variable-sized and OWN is equivalent to PL/I's STATIC.

That is not so.  There was little controversy surrounding those, because
they were almost universally regarded as a demented idea.

Quote:
>The problem is that it was necessary to introduce a method whereby a subroutine
>or function could retain information between calls.  This occurs naturalli in
>FORTRAN, since the local storage belonging to a subroutine or function is
>statically allocated.  In Algol 60 all variables are allocated upon block entry
>and deallocated upon bloce exit.  To allow routines to retain the values of
>selected local variables between calls, the designers of Algol 60 introduced the
>variable attribute OWN.  Only later was it realized that this has rather far
>reaching implications in the case of local dynamic arrays.  That is what became
>the topic of debate for at least 20 or 30 years.  It may well still be going on.

It was more-or-less settled by the time I got involved - c. 1970.
Most Algol 60 compilers did not allow dynamic OWN arrays, and most
computer science departments taught that they were a bad idea.

However, you HAVE got one of the right reasons that recursion was (and
still is) a controversial matter.  One of the traditional optimisation
techniques (heavily depended on by IBM Fortrans, many other vendors'
and a good many libraries and applications) was to have a large number
of static locations containing useful addresses.  Now, while many do
have to be recalculated each call, not all do, and there are tricks to
reuse data calculated in a previous call.

And, what is more, you can do all of that with a SINGLE stack/data
pointer if you don't allow recursion, thus saving an extra register
for optimisation.  This is quite a big matter on systems with few
registers, like the System 360/370 and Intel 80x86.  I can assure you
that the above two reasons were the main ones that IBM avoided recursion
from Fortran G & H up to VS Fortran.

Now, we come to variable sized arrays.  The reluctance here is largely
because of the ignorance of Algol 68, which is why the people pushing
them for both Fortran 90 and C90 were often ex Algol 68 programmers!
I could name names :-)

In a naive implementation, you need a extra pointer to address both
the fixed stack variables and where the stack pointer is now.  But,
in fact, you don't need to pass both in registers across routine calls
if you design the calling sequence carefully.  It is true that the
calling sequence becomes slightly slower, but it is negligibly so on
any system dominated by cache lines touched rather than instructions
executed, and that has been so in mainframes for 25 years and on PCs
for 15.

There is also the problem that you lose performance by putting such
arrays onto the stack, because you destroy locality.  But, if you put
them on the heap, you cause fragmentation.  Well, there is a a solution
to this that worked excellently in Algol 68 and could TRIVIALLY be
implemented on modern systems, but few vendors do it.  Just leave the
basic stack for the small, fixed size objects and put the larger and
variable ones in a secondary stack segment.

Experience on the IBM 3081 was that this can speed up the performance
of many programs even over the static allocation method!  And it also
improves reliability and error handling (because it means that most
forms of stack overflow are trappable without needing even a stack
overflow handling stack).

Now, I shall not go into the appalling mess that the Berkeley and GNU
people have created for C by perpetrating alloca ....

Again, the Algol 68 people could have told them WHY it is looks a neat
idea at first sight but is an implementation and portability nightmare.
It is like Algol 68 local generators but without the syntactic
safeguards.

Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.

Tel.:  +44 1223 334761    Fax:  +44 1223 334679



Thu, 07 Jul 2005 20:02:01 GMT  
 Why did they make FORTRAN so hard to parse?


Quote:

>>There were a tad annoying with just plain TECO, too.  VT50s
>>had 12 lines.  I would have trashed the damned thing if it
>>hadn't had a flat top.  Going from a VT05 to a VT50 had
>>one advantage--cup and listing shelf without a slope.

>Thank you!  I used those <censored> things back in the mid-70s, and
>I always wondered if there was *anything* good one could say about
>them.

Keyboard was an improvement over the VT05 (but only for us touch
typists).

Quote:

>The management of my PPOE was suckered into buying far too many VT50s
>as part of a deal to get a KL10.  To the best of my knowledge, management
>never discussed the selection with either the computer center or any
>of the faculty.

<GRIN>  I wonder if that's where all of our went?  ISTR that all
of a sudder all VT50s disappeared and were replaced by 52s.

/BAH

Subtract a hundred and four for e-mail.



Thu, 07 Jul 2005 19:26:28 GMT  
 Why did they make FORTRAN so hard to parse?


Quote:

>>>>wb4alm?  olden days?  Is old  before '80, '70,  '60,
>>>>'50, '40, or earlier?

>>Yes. ;-)

>Whooo,  I just squeeked by on that one. You had me worried for a minute.
>I actually thought I was getting old.

I thought about asking which century but decided to be tactful.

Quote:

>>I spent too many years looking at UPPER CASE ALL THE TIME, so I use lower
>>case whenever I can...  :-)

>>Ah, but life was so much more simple in uppercase.

>Yeah, the manners were better - it was much harder to shout!

That's when the posts were interesting.  There are some people
out there in the world who can write the most intelligent
flames.

Quote:

>>There were a tad annoying with just plain TECO, too.  VT50s
>>had 12 lines.  I would have trashed the damned thing if it
>>hadn't had a flat top.  Going from a VT05 to a VT50 had
>>one advantage--cup and listing shelf without a slope.

>I used a beanbag cup with a lid, could perch it on the edge...

Whoa.  Do you always tempt Murphy?

Quote:

>>Do a complete anti-cap and you get bill turner, wb4alm.

>>Now how would a dood interpret that?

>Some of my students couldn't get pass the "b".

All they had to do was recall the TV network that airs those
strange programs.

Quote:
> .. I think they got stressed
>out when trying to remember
>that they were trying to learn their ABC's. The only C'ing they did was
>viewing the opposite gender.

My, but kids start young.  My ABCs came first, then the ogling
although I failed the eye-batting class.  

/BAH

Subtract a hundred and four for e-mail.



Thu, 07 Jul 2005 20:12:12 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:

> A bigger irritant was that Algol 60 defined no I/O, and all systems
> used a different set of calls!

One of the strengths claimed by the C community was that it was a
small language which did not even define I/O - that was left to a
library that could be tailored to the need of the environment.

So many things which in one language are declared major weaknesses and
in another are seen as strengths.



Fri, 08 Jul 2005 07:52:58 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:



> > I asked similar question at c.l.f. recently -- the title of the thread
> > is "new user", started at Jan 9 (I was lazy to rename it, not expecting
> > so many answers). To try to summarize, it comes from the days when memory
> > was invaluable, and blanks in the memory were a pure waste; when loading
> > source into memory, compilers would remove all blanks from the punchcards,
> > then applied multi-pass algorithms to parse it.

> This was not a well thought out concept.  Imposing the requirement on
> the user to create properly formed tokens from lexemes is not
> burdensome.  And by the way fortran 77 is actually quite easy to parse
> (using a modified PL/I lexer)

Was the theory of programming languages (I am thinking of the concepts
of
LR and LARL - if I have the acronyms wrong, please forgive me, I am but
an amateur in this field), already developed enough when FORTRAN was
first developed to consider such questions?

(Note that "modern" languages like C++ are even more difficult to parse
due to all kinds of ambiguities that the compiler has to worry about)

Regards,

Arjen



Fri, 08 Jul 2005 15:30:49 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:

> Well, I would say that CONTROLLED instead of STATIC would work
> better for this problem.  The program itself, (using a STATIC flag)
> allocates the memory to the desired size when the size is known,
> and frees/reallocates it to a new size when needed.

Sure it would, but the discussion wasn't about the best way to deal with the
problem; it was about the subject of the long running debate or controversy
concerning Algol 60.


Fri, 08 Jul 2005 15:35:19 GMT  
 Why did they make FORTRAN so hard to parse?


...

Quote:
>> Was the theory of programming languages (I am thinking of the concepts
> of
> LR and LARL - if I have the acronyms wrong, please forgive me, I am but
> an amateur in this field), already developed enough when FORTRAN was
> first developed to consider such questions?

No.  Backus went on to be one of the leading people involved in
formalizing all those things.  The first specification of Fortran was
in 1954 by Backus and his team.  Formal specification of syntax
wasn't done until 1959 or so.  Analysing the properties,
and automating the processing of such formal specifications
proceded from there.  Pager's algorithm for producing efficient
LR(1) parsers wasn't published until 1977.

--
J. Giles



Fri, 08 Jul 2005 16:08:05 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:


>> A bigger irritant was that Algol 60 defined no I/O, and all systems
>> used a different set of calls!

>One of the strengths claimed by the C community was that it was a
>small language which did not even define I/O - that was left to a
>library that could be tailored to the need of the environment.

>So many things which in one language are declared major weaknesses and
>in another are seen as strengths.

Well, excluding the fact that it was a small compiler and never a
small language, that needs putting in context.  As a claim, it has
some truth but is mostly false.

stdio has ALWAYS been part of the C language system, and the separation
was more of an implementation issue than anything else.  Defining I/O
in terms of library calls was standard practice by the end of the 1970s,
though it slightly reversed in the 1980s.

Precisely the same applies to the preprocessor/compiler distinction.

Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.

Tel.:  +44 1223 334761    Fax:  +44 1223 334679



Fri, 08 Jul 2005 17:17:59 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:
> Actually I also occasionally point out the value of the first of
> these as well.  

One of the worst horrors is to look at the source of TeX or Metafont as
produced by Tangle (or was that Weave?). It put the generated code into
lines that are as filled as possible while still obeying the syntax rules.
Positively unreadable.

The least verbose while still error-resistant way is to use indentation and
a folding editor (the latter having additional advantages), as used by occam2.

        Jan



Fri, 08 Jul 2005 18:57:37 GMT  
 
 [ 114 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software