Re: syntax complexity

gah4 <gah4@u.washington.edu>
Thu, 16 Feb 2023 16:08:16 -0800 (PST)

          From comp.compilers

Related articles
syntax complexity gah4@u.washington.edu (gah4) (2023-02-15)
Re: syntax complexity tkoenig@netcologne.de (Thomas Koenig) (2023-02-16)
Re: syntax complexity DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-02-16)
Re: syntax complexity gah4@u.washington.edu (gah4) (2023-02-16)
Re: syntax complexity gah4@u.washington.edu (gah4) (2023-02-16)
Re: syntax complexity costello@mitre.org (Roger L Costello) (2023-02-20)
Re: syntax complexity gah4@u.washington.edu (gah4) (2023-02-20)
Re: syntax complexity gneuner2@comcast.net (George Neuner) (2023-02-20)
Re: syntax complexity anton@mips.complang.tuwien.ac.at (2023-02-21)
syntax complexity christopher.f.clark@compiler-resources.com (Christopher F Clark) (2023-02-21)
Re: syntax complexity nmh@t3x.org (Nils M Holm) (2023-02-21)
[1 later articles]
| List of all articles for this month |

From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Thu, 16 Feb 2023 16:08:16 -0800 (PST)
Organization: Compilers Central
References: 23-02-045 23-02-047 23-02-050
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="59118"; mail-complaints-to="abuse@iecc.com"
Keywords: Fortran, history, comment
Posted-Date: 16 Feb 2023 21:22:36 EST
In-Reply-To: 23-02-050

On Thursday, February 16, 2023 at 2:46:25 PM UTC-8, gah4 wrote:


(snip)


> When I wrote that one, I was thinking about the places where Fortran uses
> special characters and PL/I uses words.


> DO I=1,10,3


> DO I = 1 TO 10 BY 3;


> I think about them in a different way, such that the thought complexity is different.


> A compiler doesn't "think" in that way.


> I suppose I agree with the above, the length of the standard, with some
> assumptions on how it is written, or the length of the front end.


(and our moderator wrote)
> [Having written a couple of Fortran parsers, I can say that while the hacks
> to deal with ignored spaces were ugly, they weren't that hard. PL/I has a
> separate issue that the same token might be a keyword or a variable depending
> on context, and the kinds of parsers you build with bison et al don't deal
> very well with that. -John]


Well there is that, but so far I was only thinking about the difference
between commas and keywords.


            WRITE(2,*) A, B, C
            PUT FILE(TWO) SKIP LIST(A, B, C);


or


            READ(3'K) X
            READ FILE(THREE) INTO(X) KEY(K);


the funny IBM use of a single apostrophe for direct access files.


I had a part of a summer undergrad project working with the STEP
macro processor, which I wrote about some time ago.
I was writing the parser for IBM Fortran (not including leaving
out spaces between words), but there is no way to match a single
apostrophe! Parsing string constants was done at a very low level.
[Like I said the hacks were ugly. For example, this statement
contains a Hollerith constant:


123 FORMAT(4HELLO)


but this one does not:


            REAL*4HELLO


I was doing F77 which didn't do that strange quote thing but it's easy
enough to tell from context, since a quoted string has to follow a
punctuation mark that is not a close paren. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.