Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: gah4 Newsgroups: comp.compilers Subject: Re: syntax complexity Date: Thu, 16 Feb 2023 16:08:16 -0800 (PST) Organization: Compilers Central Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-02-051@comp.compilers> References: <23-02-045@comp.compilers> <23-02-047@comp.compilers> <23-02-050@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <23-02-050@comp.compilers> Xref: csiph.com comp.compilers:3390 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]