I've been following this debate and wondering just what the ISO standards define. As you know, it's not easy reading through the standards and finding obscure little details such as this. <g>
However, I think section 6.13 of ISO-10206 indicates that a program can indeed consist of multiple modules and can include one main program, each of which is terminated by a "full stop" (aka. "period").
Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When eoln(f) is activated, it shall be an error if ... eof(f) is true".
Joe.
-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Wednesday, June 05, 2002 8:00 PM To: cbfalconer@worldnet.att.net; gpc@gnu.de Subject: Re: Pascal-Standard Question
CBFalconer wrote:
Frank Heckenbach wrote:
Eike Lange wrote:
On Tue, Jun 04, 2002 at 10:16:21AM -0400, CBFalconer wrote:
Put in those terms, he is absolutely right IMO. Anything that follows the "end ." should be ignored, in fact not even read. The period should be parsed and cause compilation to stop. I think the syntax is something like:
program ::= 'program' progparms ';' declarations block '.'
Yes, but there might be a statement like this (not exactly BNF :-) part ::= program or unit file ::= part until EOF
Yes, I'd also think so. Normally, a grammar doesn't imply that anything may follow the program.
However, BP behaves like this, and GPC does so with `--borland-pascal' (but I don't think we should make this the default).
Who are you agreeing with? I hope it is me :-)
No, Eike who I quoted directly.
I actually had to go to some trouble to get this to work correctly in PascalP, because I allowed EOF to appear immediately after the '.', with no eoln. At the same time I wanted to collect source lines for a listing.
Why don't you just read it as a text file (provided PascalP was written in Pascal)? According to the standard, a text file in Pascal consists of lines, so there is always an EOLn before EOF (whether or not the external file contains a newline at the end).
Obviously, GPC (written in C) doesn't do this, either. It just processes the input character-wise and counts the newlines (for messages) and outputs it character-wise (with `--debug-source').
This characteristic is convenient for appending rambling notes after the final "end." without worrying about forming proper comments.
The question is not whether it's convenient, but whether it's allowed by the standards. Do you have any reference where they allow it?
BTW I just ran across a fascinating essay at:
<http://www.epemag.com/zuse/forword.htm>
which might especially interest you.
Gives me a 404.
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html
da Silva, Joe wrote:
I've been following this debate and wondering just what the ISO standards define. As you know, it's not easy reading through the standards and finding obscure little details such as this. <g>
However, I think section 6.13 of ISO-10206 indicates that a program can indeed consist of multiple modules and can include one main program, each of which is terminated by a "full stop" (aka. "period").
Yes, even in any order. This is rather difficult to handle, if a program precedes a required module. A way to do it is to split the source file and pass each part separately to the compiler. This could be done transparently by a preprocessor, and serve as a (more general) replacement for the current feature ...
Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When eoln(f) is activated, it shall be an error if ... eof(f) is true".
This means, in my words, that it's a runtime error to test EOLn when the file is already at EOF. However, 6.4.3.6 says:
: The structure of the type denoted by text shall define an additional : sequenceÂtype whose values shall be designated lines. A line shall be a : sequence cs~S(endÂofÂline), where cs is a sequence of components possessing : the charÂtype, and endÂofÂline shall represent a special componentÂvalue. : : [...] : : Every value t of the type denoted by text shall satisfy the following two : rules: : : a) If t.M = Inspection, then t.L~t.R shall be a lineÂsequence. : : b) If t.M = Generation, then t.L~t.R shall be ls~cs, where ls is a : lineÂsequence and cs is a sequence of components possessing the : charÂtype. : : NOTE --- 5 In rule b), cs may be considered, especially if it is nonÂempty, : to be a partial line that is being generated. Such a partial line cannot : occur during inspection of a file. Also, cs does not correspond to t.R, : since t.R is the empty sequence if t.M = Generation.
This indicates that it doesn't support partial lines at the end of the file except during writing -- whether or not that's a good idea is certainly arguable (I don't really think so) ...
Frank