Recent

Author Topic: inconsistent treatment of "end."  (Read 2001 times)

Curt Carpenter

  • Sr. Member
  • ****
  • Posts: 402
Re: inconsistent treatment of "end."
« Reply #15 on: February 20, 2024, 10:19:50 pm »
Out of curiosity, why is end. not treated as a reserved word by the compiler?

440bx

  • Hero Member
  • *****
  • Posts: 4014
Re: inconsistent treatment of "end."
« Reply #16 on: February 20, 2024, 11:23:21 pm »
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.
« Last Edit: February 20, 2024, 11:25:38 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Joanna

  • Hero Member
  • *****
  • Posts: 751
Re: inconsistent treatment of "end."
« Reply #17 on: February 21, 2024, 01:41:00 am »
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.
✨ 🙋🏻‍♀️ More Pascal enthusiasts are needed on IRC .. https://libera.chat/guides/ IRC.LIBERA.CHAT  Ports [6667 plaintext ] or [6697 secure] channel #fpc  Please private Message me if you have any questions or need assistance. 💁🏻‍♀️

Thaddy

  • Hero Member
  • *****
  • Posts: 14357
  • Sensorship about opinions does not belong here.
Re: inconsistent treatment of "end."
« Reply #18 on: February 21, 2024, 07:29:52 am »
Joanna,
The {$if 0} very long comment {$endif}trick that I suggested prevents that. Just tested on Bookworm.
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5462
  • Compiler Developer
Re: inconsistent treatment of "end."
« Reply #19 on: February 23, 2024, 10:35:34 pm »
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

  • Hero Member
  • *****
  • Posts: 4014
Re: inconsistent treatment of "end."
« Reply #20 on: February 23, 2024, 11:09:28 pm »
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)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 14357
  • Sensorship about opinions does not belong here.
Re: inconsistent treatment of "end."
« Reply #21 on: February 23, 2024, 11:26:27 pm »
Hm. In this case I agree  :o
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6682
Re: inconsistent treatment of "end."
« Reply #22 on: February 23, 2024, 11:42:49 pm »
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018