Newsletter #9-#10 - Moorecad.com

What is a Textfile?
The PASCAL revised report, section 6.2.4 in particular, is in serious
error as to the nature of textfiles.
by -- the definition of type TEXT as FILE OF CHAR.
This error arises -- or is demonstrated
(As a typographicalconvention,
program fragments are presented in upper case, and the pointer operator,
up-arrow, is representedby the character @).
As a result of this lapse,
complex special-casenotions are introduced as primitive concepts. Please
notice that I am not advocating a change in the language, or an abolition of
existing notation:
definition of the textfile notion.
First, consider the files F and G:
F: TEXT;
G: FILE OF FILE OF CHAR.
I merely propose a new, more useful, understanding and
Obviously, a READ or WRITE performed on F will perform the same on G@, the
"inner" file in G. Some of the auxiliary r/o constructs, however~ change in
a very enlightening fashion: reviewing all available literature on the
semantics
of PASCAL file operations, we conclude that
WRITELN(F)
READLN(F)
EOLN(F)
becomes
becomes
bec ames
PUT (G),
BEGIN WHILE NOT EOF(G@) DO GET(G@): ~ET(G) END, and
EOF(G)!
implied by WRITELN, READLN, and EOLN, a
each line is a file of characters.
We conclude that to supply the structure
textfile is at least a file of lines, where
There is even more to a textfile: we haven't considered the PAGE statement.
Let's add another
declaration:
H: FILE OF FILE. OF FILE OF CHAR.
Now, anywhere we used G, we can use H@:
of READLNchanges.
the addition of the PAGE statement:
logically, however, the re-representation
The wholeset of equivalentconstruct-pairs becomes,with
WRITELN(F)
EOLN(F)
PAGE(F)
PUT(H@),
EOF(H@),.and
PUT(H).
At this point, we have developed the structure that is necessary and
sufficient to support all the standard textfile operations. As an added
benefit (or is it a side effect?) we have a better appreciation of the
embedded file, or file-of-file, concept. Before running off to reimplement
textfiles the new way into your favorite compiler, however, let's give some
thought to extensibility.
If a textfile is considered as merely a nest of files, then those
implementations which would like to give access to such things as page
numbers, line numbers, and vertical printer spacing ("carriage control") will
have to kludge those features in as primitives: thus we would be back where
we started. If, however, we consider TEXT to be predeclared as follows,
we notice some nice hooks:
TYPE TEXT: RECORD
END;
END
(*EXTERNAL FILE NAME, ETC*)
P :FILE OF RECORD
(*PAGENUMBER*)
L:FILE OF RECORD
END
(*LINENUMBER*)
(*SPACING*)
C:FILE OF CHAR
The comments point out places where interesting implementation-dependent
features caD reside.
READ (F) .;.
WRITE (F)
READLN(F)
READ(H@@),
WRITE(H@@),
BEGIN WHILE NOT EOF(H@@) D0 GET(H@@):
IF NOT EOF(H) THEN
William C. Price
28282 SW Mountain Rd.
West Linn, OR 97068 USA
(* Received 77/06/10 *)
IF EOF(H@) THEN GET(H) ELSE GET(H@)
END,
WCP:pt
- 1 -
- 2 -