Scott Moore wrote:
Also the filename seems problematic to me. What if several files are opened to the same file name? Then add the problems if directories were changed (as discussed recently in a similar situation). I don't think we want to emulate this ...
UCSD was interpretive, so using the name string has the primary method of identifying a file was not a speed problem. Its a pretty good example of how implementation assumptions don't generalize well.
Yes, but I wasn't talking just about speed, also about ambiguities (both with several files open for the same name and with changed directories).
Using "word symbols" is actually the recommended method to use (standardwise) to prevent polluting the reserved tolken space. For example, "forward" and "external" are "word symbols". There are, or were, whole languages that work like that, leading to lots of ambiguous constructs.
Well, constants don't pollute this space either, since they're not reserved. Otherwise, a magic integer (or char or whatever) value would have served quite well. Personally I find it quite gross to introduce a "word symbol" (which is outside the regular syntax, i.e. it can't be defined by Pascal code, and it requires special parsing) just for one single routine.
BTW, I don't find evidence of this as a "recommended method" in the standards. In fact, they say: "No identifier shall have the same spelling as any word-symbol." So a "word-symbol" is (the standard's terminology for) a reserved word. The standards mention directives (if you mean these), but "A directive shall only occur in a procedure-declaration or a function-declaration. The only directive shall be the required directive `forward'". `external' is also non-standard, there's only a note that says: "Many processors provide, as an extension, the directive `external' [...]".
Scott Moore wrote:
A table follows, listing the actions caused by certain characters in that first position of a printed line...
Symbol Action ----------- --------------------------------- blank space advance one line before printing 0 (zero) advance two lines before printing 1 skip to top of next page before printing + do not advance (will overprint)This is the original print line convention proposed by Wirth. It was discarded for the ISO standard.
Thank God! (For fear of getting into another flamewar about CR/LF conventions and the corresponding C syntax, I'll leave it at that. ;-)
Frank