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


Quote:

> > Same thing in PL/I,  DECLARE( ....) IIRC has to be scanned all
the way to
> > the closing parenthesis before
> > the parser can figure out if this is a DECLARE statement, or
something else.

> All the way to the next token after the closing parenthesis, but
this
> isn't really a problem: just keep stacking the stuff until you
get to
> the right paren.  There are only a few cases in PL/I that need a
> look-ahead of nore than one or two tokens.

> fortran is hard to parse, I believe, because when it was invented
no one
> knew enough about parsing to define a good grammar.  PL/I is hard
> because the idea was that the programmer shouldn't need to know
about
> features he/she isn't using.  If all you do is stream I/O, you
don't
> need to know READ and WRITE, etc.

I believe this is very important for a language that can be
extended in the future.  PL/I has many keywords that most
programmers will never need to use, or even know about.  Supplying
a large list of reserved words, as COBOL does, makes it difficult
for the programmer.

I have seen C compilers that refuse a variable named new.  Note
that new is not a C keyword!  Keywords have been added to
languages, which destroys backward compatibility for programs
written to the older standard, as they might have used those words.

-- glen



Sat, 02 Jul 2005 18:40:11 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:

... snip ...

> I have seen C compilers that refuse a variable named new.  Note
> that new is not a C keyword!  Keywords have been added to
> languages, which destroys backward compatibility for programs
> written to the older standard, as they might have used those words.

Then it is NOT a C compiler.  Maybe a misused C++ compiler.

--

   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!



Sat, 02 Jul 2005 20:10:36 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:




> > > Same thing in PL/I,  DECLARE( ....) IIRC has to be scanned all
> the way to
> > > the closing parenthesis before
> > > the parser can figure out if this is a DECLARE statement, or
> something else.

> > All the way to the next token after the closing parenthesis, but
> this
> > isn't really a problem: just keep stacking the stuff until you
> get to
> > the right paren.  There are only a few cases in PL/I that need a
> > look-ahead of nore than one or two tokens.

> > FORTRAN is hard to parse, I believe, because when it was invented
> no one
> > knew enough about parsing to define a good grammar.  PL/I is hard
> > because the idea was that the programmer shouldn't need to know
> about
> > features he/she isn't using.  If all you do is stream I/O, you
> don't
> > need to know READ and WRITE, etc.

> I believe this is very important for a language that can be
> extended in the future.  PL/I has many keywords that most
> programmers will never need to use, or even know about.  Supplying
> a large list of reserved words, as COBOL does, makes it difficult
> for the programmer.

> I have seen C compilers that refuse a variable named new.  Note
> that new is not a C keyword!  Keywords have been added to
> languages, which destroys backward compatibility for programs
> written to the older standard, as they might have used those words.

> -- glen

Any language thats as easy to read as Fortran is easy to parse, colleges dont offer fortran training
because the language has a rep for being easy to pick up on your own.

Fortran standard encourages (but does not demand for backward compatibility) a break in the governing
declaration
and the individual items using that declaration with a ::
    ie.     real,parameter :: pi = 3.14, twopi = pi*2



Sat, 02 Jul 2005 21:26:42 GMT  
 Why did they make FORTRAN so hard to parse?


Hey, Kid!  See that funny looking key marked Enter with an arrow?
Please use it.

Quote:




Quote:




>> > > Same thing in PL/I,  DECLARE( ....) IIRC has to be scanned all
>> the way to
>> > > the closing parenthesis before
>> > > the parser can figure out if this is a DECLARE statement, or
>> something else.

>> > All the way to the next token after the closing parenthesis, but
>> this
>> > isn't really a problem: just keep stacking the stuff until you
>> get to
>> > the right paren.  There are only a few cases in PL/I that need a
>> > look-ahead of nore than one or two tokens.

>> > FORTRAN is hard to parse, I believe, because when it was invented
>> no one
>> > knew enough about parsing to define a good grammar.  PL/I is hard
>> > because the idea was that the programmer shouldn't need to know
>> about
>> > features he/she isn't using.  If all you do is stream I/O, you
>> don't
>> > need to know READ and WRITE, etc.

>> I believe this is very important for a language that can be
>> extended in the future.  PL/I has many keywords that most
>> programmers will never need to use, or even know about.  Supplying
>> a large list of reserved words, as COBOL does, makes it difficult
>> for the programmer.

>> I have seen C compilers that refuse a variable named new.  Note
>> that new is not a C keyword!  Keywords have been added to
>> languages, which destroys backward compatibility for programs
>> written to the older standard, as they might have used those words.

>> -- glen

>Any language thats as easy to read as Fortran
>is easy to parse, colleges dont offer fortran training
>because the language has a rep for being easy to pick up on your own.

I didn't think COMMON and EQUIVLENCE was easy to pick up.
I had instruction and it still wasn't easy to pick up.
That FORMAT statement isn't all that easy to pick up either;
anybody can eat/throw garbage on I/O.  And the PLOTTER wasn't
very easy.  And the all of those intrinsic functions assumed
you knew a lot of things.

If profs are thinking this, they need certain external
anatomy parts kicked.

Quote:

>Fortran standard encourages (but does not demand
>for backward compatibility) a break in the governing
>declaration
>and the individual items using that declaration with a ::
>    ie.     real,parameter :: pi = 3.14, twopi = pi*2

Sigh!  Backwards compatibility breakage is a known fact of
life.  So the unwritten rule is that you make your choice
of variable names with some modicum of intelligence.  It
was easy to do in COBOL but took a few brains to ensure
forwards-compatibility in FORTRAN.

And note that this flavor of compatibility only is a problem
at _compile time_, not execution time.  Our more difficult
design problems was to ensure that old executables still
ran under the newer version of the OTS (operating-time system).

/BAH

Subtract a hundred and four for e-mail.



Sat, 02 Jul 2005 21:20:42 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:


> Hey, Kid!  See that funny looking key marked Enter with an arrow?
> Please use it.

below contains 80 columns when I read my posted message back from the newsgroup, same as I posted.
12345678901234567890123456789012345678901234567890123456789012345678901234567890
How did you manage to get on the internet with your 40col Apple computer and even use lower case text?


Sat, 02 Jul 2005 22:25:05 GMT  
 Why did they make FORTRAN so hard to parse?
[...]

Quote:
> below contains 80 columns when I read my posted message back from the
> newsgroup, same as I posted.

Over the wire, your posts only have CRLFs at the end of each paragraph.
Email and news convention is to have a CRLFs at the end of each line, before
column 80. (Because it wouldn't fit on a punch card otherwise :)

Outlook is good at generating such broken text and then hiding the problem.
In this case, it's omitting to chop the lines, and is word-wrapping them for
display. That's what you get for using what is practically a wordprocessor
for writing email and news.



Sat, 02 Jul 2005 23:14:17 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:


> [...]
> > below contains 80 columns when I read my posted message back from the
> > newsgroup, same as I posted.

> Over the wire, your posts only have CRLFs at the end of each paragraph.
> Email and news convention is to have a CRLFs at the end of each line, before
> column 80. (Because it wouldn't fit on a punch card otherwise :)

> Outlook is good at generating such broken text and then hiding the problem.
> In this case, it's omitting to chop the lines, and is word-wrapping them for
> display. That's what you get for using what is practically a wordprocessor
> for writing email and news.

I am using Outlook Express, and why did you not quote my text as it would have perhaps let some
light into whats happening if your newsreader chopped my text into more than the 3 lines posted.
(above is 2 lines leaving my desktop, AND I expect to see 3 lines arriving back here from the
newsgroup, if its something other than WYSIWYG for you, SORRY 'BOUT THAT!


Sat, 02 Jul 2005 23:53:03 GMT  
 Why did they make FORTRAN so hard to parse?


Quote:



>> Hey, Kid!  See that funny looking key marked Enter with an arrow?
>> Please use it.

>below contains 80 columns when I read my posted message back from the

newsgroup, same as I posted.
Quote:
>12345678901234567890123456789012345678901234567890123456789012345678901234
567890
>How did you manage to get on the internet with your 40col Apple computer

and even use lower case text?
Honey, you need a kindergarten refresher course.

You're also posting to alt.folklore.computers.  You might want
to shut your mouth before and old fart sees it open.

/BAH

Subtract a hundred and four for e-mail.



Sat, 02 Jul 2005 23:24:24 GMT  
 Why did they make FORTRAN so hard to parse?


Quote:




Quote:

>> [...]
>> > below contains 80 columns when I read my posted message back from the
>> > newsgroup, same as I posted.

>> Over the wire, your posts only have CRLFs at the end of each paragraph.
>> Email and news convention is to have a CRLFs at the end of each line,
before
>> column 80. (Because it wouldn't fit on a punch card otherwise :)

>> Outlook is good at generating such broken text and then hiding the
problem.
>> In this case, it's omitting to chop the lines, and is word-wrapping them
for
>> display. That's what you get for using what is practically a
wordprocessor
>> for writing email and news.

>I am using Outlook Express, and why did you not quote my text as it would

have perhaps let some
Quote:
>light into whats happening if your newsreader chopped my text into more

than the 3 lines posted.

Quote:
>(above is 2 lines leaving my desktop, AND I expect to see 3 lines arriving
back here from the
>newsgroup, if its something other than WYSIWYG for you, SORRY 'BOUT THAT!

We're doing that reformatting by hand you idiot!!!!  We do that
so that the damned post is readable by more than computers.

Have you ever heard the terms machine-readable and human-readable?

/BAH

Subtract a hundred and four for e-mail.



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

Quote:



> > Hey, Kid!  See that funny looking key marked Enter with an arrow?
> > Please use it.

> below contains 80 columns when I read my posted message back from the newsgroup, same as I posted.
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> How did you manage to get on the internet with your 40col Apple computer and even use lower case text?

Obviously you didn't post in under 80 columns.  65 is a better
value anyhow.

--

   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!



Sun, 03 Jul 2005 00:52:38 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:

> I am using Outlook Express, and why did you not quote my text as it would
> have perhaps let some
> light into whats happening if your newsreader chopped my text into more
> than the 3 lines posted.

Looks to me like your Outlook Express is chopping the lines around 92-93
characters out.  

When I toggle word wrapping in slrn, I can read your postings, but I see
four broken lines like the above (four lines, two of them shorter than the
others).  

When I don't toggle word wrapping in slrn (the default), your lines extend
well beyond the 80-column screen boundary.

Quote:
> (above is 2 lines leaving my desktop, AND I expect to see 3 lines
> arriving back here from the
> newsgroup, if its something other than WYSIWYG for you, SORRY 'BOUT THAT!

This sort of thing has been a problem with Outlook (and some of the other
so-called WYSISYG newsreaders) for some time.  The accepted standard in
many newsgroups is to add a hard End-of-line to each line of the posting,
and to do so within the 80-column limit that exists on common terminals.

--
 -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
                     Written online using slrn 0.9.5.4!
                   The Theorem Theorem: If If, Then Then.



Sun, 03 Jul 2005 01:07:00 GMT  
 Why did they make FORTRAN so hard to parse?

Quote:


> > FORTRAN is hard to parse, I believe, because when it was invented
> > no one
> > knew enough about parsing to define a good grammar.  PL/I is hard
> > because the idea was that the programmer shouldn't need to know
> > about features he/she isn't using.

Certainly explains Fortran77 and predecessors.
Doesn't explain F95.

But much of the problem with parsing isn't the languages, it is use
of lousy parsing technology.   Most of the world believes YACC
is the parsing technology of choice.  YACC directly handles
languages whose grammars are categorized as LALR(1).

Only ISO Pascal has a grammar that meets that constraint,
of the languages I know about.  All the rest of them require
either many-tokens-of-lookahead (JavaCC sort of does OK
at this), or possibly infinitely many lookahead tokens,
(FORTRAN via format statements) or are ambiguous at the grammar level
(C++, FORTRAN and DO-statements with shared CONTINUE ends).
Consequently people try to use YACC; it doesn't work very
well, and they hack at their parsing engines to cover up
the weakness.  Thus the widespread folk theorem, "...hard to parse".

However, there are perfectly good parsing technologies
that can parse of all these "easily" in the sense that you give
them a grammar (without much hacking from the reference
grammer) and they work fine.   GLR parsing is one example
(see discussion in comp.compilers this month).
GLR parsing provides full context free parsing, which
covers all the above cases nicely.

We provide tools for processing source programs that
use GLR parsing, and "easily" parse all the major languages.

Including FORTRAN.

--
Ira D. Baxter, Ph.D., CTO   512-250-1018
Semantic Designs, Inc.      www.semdesigns.com



Sun, 03 Jul 2005 04:17:02 GMT  
 Why did they make FORTRAN so hard to parse?


Quote:
> Over the wire, your posts only have CRLFs at the end of each paragraph.
> Email and news convention is to have a CRLFs at the end of each line, before
> column 80. (Because it wouldn't fit on a punch card otherwise :)

Default seems to be at col 72, in my experience.  Can't imagine why....
:->  I mean, who's going to add a comment in the final 8 cols??

--
Today, on Paper-view: The World Origami Championship



Sun, 03 Jul 2005 08:10:31 GMT  
 Why did they make FORTRAN so hard to parse?

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net



Quote:


> > Over the wire, your posts only have CRLFs at the end of each paragraph.
> > Email and news convention is to have a CRLFs at the end of each line,
before
> > column 80. (Because it wouldn't fit on a punch card otherwise :)

> Default seems to be at col 72, in my experience.  Can't imagine why....
> :->  I mean, who's going to add a comment in the final 8 cols??

Do you put continuation characters in col 6 when you post
multi-line posts? Usually card sequence numbers in those
last columns, so you could recover from dropping your
program on the floor. Did that with four boxes of cards once.

Recovery was quite simple :-)

--

   ...  Hank

Chaos, panic, and disorder - my work here is done.



Sun, 03 Jul 2005 10:20:44 GMT  
 Why did they make FORTRAN so hard to parse?


(snip)

Quote:

> Do you put continuation characters in col 6 when you post
> multi-line posts? Usually card sequence numbers in those
> last columns, so you could recover from dropping your
> program on the floor. Did that with four boxes of cards once.

> Recovery was quite simple :-)

If you have a card sorter around, but who has one of those these
days.

You could read it in, sort it, then punch it back out again!

-- glen



Sun, 03 Jul 2005 10:29:54 GMT  
 
 [ 114 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

 Relevant Pages 

1. Why are most HPC done in Fortran?

2. A suggestion for making ruby more realtime and parallel (and it may not be too hard)

3. Why did they make FORTRAN so hard to parse?

4. making python man pages looks hard

5. Parsing - What am I doing wrong?

6. Why so hard to get started in Eiffel?

7. Why is Rexx hard to compile.

8. Why are Variables so hard to monitor?

9. Why JPython for the hard stuff?

10. why is tree-shaking hard?

11. why why why oh why why baby

12. Why is SetKey doing something different?

 

 
Powered by phpBB® Forum Software