Scott Moore wrote:
UCSD has the form:
close(filename, option)
Where option is a "word":
normal lock purge crunch
Note that a filename (not handle or var file reference) is used, and that "word" as option pretty much requires close to be a compiler built-in statement.
Ugh. So they are not even predefined constants?
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.
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.