Re: syntax complexity

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]

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