CBFalconer wrote:
I am sure you are talking about the apparent variadic nature of writeln, which does not exist. writeln is a simple function, with some compiler shortcuts applied. First, the compiler can recognize that the first parameter is not a file, and supply the identifier 'output'. That is the only parameter to writeln, the others are again the result of compiler shortcuts, specified in the standard.
Assuming the first parameter is not a file, so the default above applies, "writeln(a);" is expanded to read "write(a); writeln". This is coupled with the equivalent expansion of "write(a, b);" to "write(a); write(b);". There are equivalents for read and readln.
I agree here.
Proper use of the standard mechanism allows almost anything to be attached to the file system with clear semantics. This includes such things as complete screens, LANs, pipes, etc. No need for so-called CRT units, although they may be convenient.
I don't agree here. The Pascal file system only allows for sequential read or write access (ISO 7185), or record-based random access (ISO 10206). A CRT unit does much more than this.
To start with, coordinates are two-dimensional. Of course, you could compute a sequential offset yourself, but this doesn't exactly sound like a high-level language to me.
Then, there are "attributes" (e.g., character color). Of course, you could define a record containing attribute and character as fields and create a pseudo-file of those. That's not very convenient to use -- writing strings has to be done char by char. Also, while it can be efficient on direct memory-mapped graphics (i.e., basically, Dos), it becomes harder and less efficient on most other terminals (where the backend would have to compare attributes, generate control sequences etc.).
How do you handle the cursor position? Placing it at the current position as set by SeekWrite is (a) ISO 10206, and (b) not always useful as the cursor would jump too much.
Similarly, how would you handle automatic scrolling etc.? Writing the last (lower-right) character) should often not result in scrolling. Writing the next character would be logical, but conceptually be out of range.
If you want control over the cursor shape etc., you'd need quite some tricks to stick this into the file model.
On the input side, there's an essential difference to regular files. Regular files can be at EOF or not at EOF. In the first case, no data can be read until the file is reset (or similar) again. CRT input can also be waiting for input. Defining this state as EOF doesn't work. E.g., one could be in the middle of entering a number. EOF would mean the number is finished, but in fact the user might type more digits. This issue doesn't apply to CRT only, but also to other forms of interactive input such as pipes, networks etc. For pipes, e.g., the difference between EOF (pipe writing end closed) and waiting for data is very essential.
Furthermore, you'd have to encode function keys as char sequences. Actually, BP's CRT unit does this, but it's not really convenient when you want to handle function keys. Offering a larger type which can hold function keys and regular chars, as our CRT unit does, is really nicer to use.
Frank