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



|> > 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.

This is compounded by the error of having ad-hoc, inconsistent and
inflexible line-splicing syntax.  TeX, the Unix shells and other
programs make this one :-(

fortran isn't perfect in this respect, but isn't too bad.

|> 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.

Hmm.  I dispute that it is the least verbose, but it is certainly a
reasonable approach.

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 19:33:24 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:




> > |> >
> > |> > This was not a well thought out concept.
> > |>
> > |> Maybe you should tell John Backus that. He's still alive, living in
> > |> California, and would surely be happy to be told of all the things he got
> > |> wrong in the mid-1950s designing the world's first high-level language.

> > Being a mere tyro, I wasn't in this game at that time, but I can
> > remember that this was one of the topics used in the Fortran
> > versus Algol) wars that were still going strong in the late 1960s
> > and early 1970s.  As far as I recall, Algol 60 was the first
> > language with a modern syntax - and, boy!, was THAT controversial!

> Most of the "modern" languages have two low-level syntax features
> worse than the original Fortran (IMO).

> 1. Significance of end-of-line

> 2. keyword/end keyword form of constructs (Giles often points out
>     that this is less error prone, if I remember correctly).

> It is interesting that the shell scripts (even C-shell) does
> both of these things the Fortran way.

One of the more widely used modern languages (VB, assuming I'm not
completely missing the sense in which you used "modern") behaves the
same as Fortran in both regards (and shares a fair amount in common
in other areas as well).


Fri, 08 Jul 2005 23:54:31 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.

The cases aren't parallel in practice.  C has always had stdio.h.  ALGOL
60 never had any I/O at all.  "That's an implementation detail," they
decided.  As a result, although some systems used very extended and
altered dialects as the system-programming language, pure ALGOL 60 was
almost entirely limited to paper publishing of algorithms in the US.

Most languages put I/O into the library, today.  PL/I, FORTRAN, COBOL
and BASIC are all equally old-fashioned in having I/O in the language.
But modern languages also include the library in (or with) the
specification, and ALGOL 60 didn't, apart from a tiny set of math functions.

--
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"



Sat, 09 Jul 2005 02:41:37 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:

>Being a mere tyro, I wasn't in this game at that time, but I can
>remember that this was one of the topics used in the Fortran
>versus Algol) wars that were still going strong in the late 1960s
>and early 1970s.  As far as I recall, Algol 60 was the first
>language with a modern syntax - and, boy!, was THAT controversial!

I wrote my first Fortran II program in 1963 and changed to Algol 60 in
1964. The story then was that when someone asked Backus about the
relative merits of Fortran and Algol and he said "You don't suppose I'd
invent a worse language that I'd already invented do you?"

Backus was of course one of the authors of Algol not long after he
wrote the first Fortran. IMHO Fortran took over 30 years to catch up:
arrays whose size was found at run-time weren't in the standard until
f90. Algol was much faster to include at least one Fortran good idea:
its complex data type came in with a68. (What happened to a68?)

John Harper, School of Mathematical and Computing Sciences,
Victoria University, PO Box 600, Wellington, New Zealand



Sat, 09 Jul 2005 06:58:04 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:


> > FORTRAN has (or had, I haven't checked the Fortran 90 & 95 standards
> > recently) another characteristic that made parsing difficult: spaces
> > aren't significant.  That is:

> >      DO10I = 1, 1   0

> > is equivalent to:

> >      DO 10 I = 1, 10

> Still does for the fixed-form source.
> The free form source that is also available from F90 does not.

Fortran is not particularly hard to parse.  It is easier to parse
than either C or C++.  Parsing FORTRAN 77 is about as hard as parsing
standard Pascal.  Parsing Fortran 95 is more difficult than parsing
FORTRAN 77, but it is still easier than C and much easier than C++.

Almost all the ad hoc-ery of parsing Fortran is in the lexical analysis
phase.  A few rules take care of all the problems.  Yes, the rules
require long, though bounded, lookahead, but they are not hard to apply.

                                                   Sincerely,
                                                   Bob Corbett



Sat, 09 Jul 2005 18:36:19 GMT  
 Why did they make FORTRAN so hard to parse?


|>
|> Fortran is not particularly hard to parse.  It is easier to parse
|> than either C or C++.  Parsing FORTRAN 77 is about as hard as parsing
|> standard Pascal.  Parsing Fortran 95 is more difficult than parsing
|> FORTRAN 77, but it is still easier than C and much easier than C++.

Fortran 66 was harder than Fortran 77, of course, and some extended
Fortran 77s were nightmares.

|> Almost all the ad hoc-ery of parsing Fortran is in the lexical analysis
|> phase.  A few rules take care of all the problems.  Yes, the rules
|> require long, though bounded, lookahead, but they are not hard to apply.

Bounded?  Only by the total length of a statement!  There are some
more-or-less arbitrary look-ahead rules, too, but I don't think that
any are needed for parsing.

Similarly, the problems with parsing C (which I agree are a nightmare)
are almost all in the preprocessor.

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



Sat, 09 Jul 2005 20:00:30 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.<snip>

But the design of PL/I started a couple of years after Algol 60 and took several
years to complete.  At the time of the publication of the Algol 60 report IBM's
systems had no support for dynamic memory management or recursion. While both could
be emulated on their systems, at that time the impact on efficiency, particularly
for recursion, was considered unacceptable.  By the late 60s they had recognized the
inevitable and had started incorporating the needed capabilities into their systems.
But for a significant period in the sixties, representatives of IBM indicated that
that the unpredictability of resource availability associated with these
capabilities made them dangerous for general use.


Sun, 10 Jul 2005 00:42:46 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:

>But the design of PL/I started a couple of years after Algol 60 and took several
>years to complete.  At the time of the publication of the Algol 60 report IBM's
>systems had no support for dynamic memory management or recursion. While both could
>be emulated on their systems, at that time the impact on efficiency, particularly
>for recursion, was considered unacceptable.  By the late 60s they had recognized the
>inevitable and had started incorporating the needed capabilities into their systems.
>But for a significant period in the sixties, representatives of IBM indicated that
>that the unpredictability of resource availability associated with these
>capabilities made them dangerous for general use.

Yes, indeed, and the debate was by no means over within IBM in the
1970s.  One of the common complaints about PL/I (and I mean even the
Checkout and Optimising compilers, not PL/1 F) was that its calling
sequence was much slower than Fortran's.  Quite a few IBM people used
to say that PL/I was for power and Fortran for speed.

The joke was that you could produce a Fortran compatible calling
sequence that ran at nearly double the speed, by shuffling the data
areas to reduce the number of unpredictable branches, cache lines
touched and potential page faults.  But we never persuaded IBM that
was the issue and not the functionality ....

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



Sun, 10 Jul 2005 01:11:35 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:


> ...
>> Most of the "modern" languages have two low-level syntax features
>> worse than the original Fortran (IMO).

>> 1. Significance of end-of-line

>> 2. keyword/end keyword form of constructs (Giles often points out
>>     that this is less error prone, if I remember correctly).

>> It is interesting that the shell scripts (even C-shell) does
>> both of these things the Fortran way.

In Bell Labs back then C was just another programming language from
somebody down the hall.  

Quote:
> Actually I also occasionally point out the value of the first of
> these as well.  There were productivity experiments in the '70s
> on the subject of line-wrap in source code.  In one case, 47%
> of all syntax errors in programs submitted to a given Pascal
> compiler were missing semicolons.  More than half were
> missing at the end of the line.  The paper concluded that users
> tended to regard the end of a line as synonymous with the end
> of a statement and that's why they repeated made the error.

What actually annoys me the most about many "modern" language
designers is their ridiculous attitude that syntax doesn't really
matter.

Apparently since syntactic transformations and parsing is now a fairly
matured and settled subject algorithmically, it is implicitly---and
erroneously----assumed that humans ought to find the various forms as
equivalent as parsers do.

The issue is defined away and dismissed.  {XSLT is an example of the
horrifying limiting point of this attitude}

This notion is occasionally used to debase the value judgements of
people, and in fact sometimes, to disparage the skill of those who for
whatever intuitive human reasons find they prefer some kinds of syntax
over others.  Othertimes proponents of ergonomic languages are accused
(ridiculously) of trying to turn them into some kind of antideluvian
remake of COBOL.

In the commercial world, Java and C# both adopted superficial
syntactical aspects of C in a cargo-cultish attempt to imitate its
success.  (Add ''JavaScript'' as a second-level imitation of
imitation)

Few bothered to think carefully about the design of its syntax as
opposed to their object models and type system (Java isn't so hot here
either).

Whatever C's strengths are (and it has some), its inadequacies and
misfeatures certainly start with its unergonomic syntax.

The actual scientific psychological results (however thin they are)
are almost completely ignored by the bulk of commercially oriented
language design.

There's one language designer who didn't follow contemporary 'modern'
trends in language design, but instead made other even more egregious
errors justifying them with an entirely wrong interpretation of human
linguistics.  {notably that natural langauges are the way they are
because built-in human brain circuits are evolved to process them
well, and thus unless an artificial langauge is similarly
automatically learnable by children under 2, designing artificial ones
similarly can be very mistaken.}

That blunder was the seed encrufted by layers of sparkly braincandy,
that makes a perl.

Quote:
> J. Giles



Sun, 10 Jul 2005 04:58:40 GMT  
 
 [ 114 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software