inconsistent treatment of "end."

[Curt Carpenter]

Out of curiosity, why is end. not treated as a reserved word by the compiler?

[440bx]

Out of curiosity, why is end. not treated as a reserved word by the compiler?

because "end" is a reserved word and "." is a delimiter, that, for practical purposes, prevents the parser from considering the combination as a reserved word.  An example will make why clear.

Between any delimiter and reserved word you can have a comment, for instance "end {this is a comment } ;" (note the semicolon.) if the parser wanted to treat the "end;" combination as a reserved word, it would have quite a problem with the comment.  It would actually require the parser to look a complete token (the comment) ahead to determine if there is or isn't a reserved word there.  The great majority of parsers (PL/1 comes to mind as an exception) depend on inspecting no more than the _next character_ (not token but, a single character) to determine if they have completed the scanning of an identifier or reserved word.   Breaking that rule creates a great deal of complications and can severely negatively impact scanning and parsing performance.

The original FORTRAN language was said to require it being parsed before it could be scanned because of things like that (which is one of the things that prompted the study of language grammars.)

ETA:

I guess in spite of all of the above, the language could make an exception of "end' followed by a period but, it's not within the spirit of the language's grammar.

[Joanna from IRC]

I don’t do any c programming but I am in the habit o f stashing old code after end. Until I’m sure I don’t need it anymore.
On windows os this works fine but when I tried to compile same file on fedora Linux  Awhile ago , it was complaining about code after the end.

[Thaddy]

Joanna,
The {$if 0} very long comment {$endif}trick that I suggested prevents that. Just tested on Bookworm.

[PascalDragon]

Out of curiosity, why is end. not treated as a reserved word by the compiler?

Also there could be code like this (not saying that it's a good idea to do something like this, but the compiler should handle it as gracefully as possible):

Code: Pascal  [Select][+][-]

1.   // bla bla
2. {$ifndef SomeDefine}
3. end.
4. {$else}
5.   // bla bla
6. end.
7. {$endif}
8.  

In this case the $endif needs to be consumed as otherwise there's a dangling if-clause.

[440bx]

That's a nasty example

I think it would be reasonable for the language definition to state that _nothing_ will be honored after scanning the sequence "end" "." and emit a  message warning that text after the "." has been ignored (which is what Delphi does)

[Thaddy]

Hm. In this case I agree 

[MarkMLl]

I think it would be reasonable for the language definition to state that _nothing_ will be honored after scanning the sequence "end" "." and emit a  message warning that text after the "." has been ignored (which is what Delphi does)

Going back to the ALGOL implementation that introduced that: it's "end." as a single token without whitespace.

ALGOL-60 had odd semantics, with- in general- anything after end treated as a comment hence "end if", "end myFunction" and so on. However at the same time it also defined that "; is a separator, not a terminator", and in combination the two cases are- at best- messy.

So I think that either "end." or "end" "." marking the end of a program is reasonable, and TBH I'd vote for anything that followed that being available as input text. If one wants to hide malformed working code etc. one should put it before the "end." demarcated with {$ifdef etc., after the "end." the input stream can no longer be regarded as Pascal so Pascal's rules relating to comments and pragmata cannot be assumed to apply.

MarkMLl