Peter N Lewis wrote:
At 6:34 -0400 24/7/05, CBFalconer wrote:
Peter N Lewis wrote:
New(s,57) gives a runtime error on failure, and so the compiler knows that it need not bother checking.
s := New(String,57) potentially returns nil, so the compiler checks.
I'm not sure if that is reasonable. It makes a certain kind of sense in some respects - New as a procedure has no return value and thus nothing to report, New as a function returns a pointer (even for reference objects anyway) and therefore can return a success/failure result.
To start with, new is a standard PROCEDURE, not a function.
New (builtin) is both a procedure and a function. From the documentation:
That is simply wrong. See section 6.7.5.3 of ISO 10206.
... snip ...
I'm not talking about overriding the New builtin. It is not possible to write a procedure with the semantics of the builtin New in Pascal (this has always seemed a weakness of Pascal to me, that it includes procedures like WriteLn and New that cannot actually be written in the language, but that is more a philosophical question).
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.
You are perfectly free to replace the functions read, write, readln, writeln with your own. Since the parameterization of those replacements is not known in advance, the handy default and expansion mechanisms can not be expected to apply.
No philosophy is required. The actual mechanism, and even the further expansion of read and write to use get, put, and f^, are clearly spelled out in the standard. The fact that Borland ignored these requirements, to no advantage, has caused great difficulty in the past and done great damage to the language.
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 can speak with confidence because I did exactly that over 25 years ago. That does not, of course, mean that that file system code can necessarily be written in Pascal.