vix@well.UUCP (Paul Andrew Vixie) (03/07/86)
Magic I/O in Modula-2
I thought of this a few years ago; by now it is too late to hope for it to be
accepted in the language standard, but here it is as a curiousity...
"Magic I/O" is how Pascal I/O works: "Magic" because it cannot be simulated by
the user. Witness that there is no mainstream version of Pascal in which the
user could implement his own WriteLN() function, or even describe it as an
external routine.
What is needed is a variable parameter list to a function - something along the
lines of C's argc/argv. The type is obviously not passable; the address
and (maybe) the size would be about all you could ask.
Since types would not be determinable by the called routine, WriteLN() would
still not be possible. However, printf() could be not only described, but
implemented portably. Thus also fprintf(), sprintf(), *scanf() . . .
All parameters would have to be passed by address - which would either be very
inconvenient (putting numeric and character constants into variables before
passing them) or a violation of the standard (passing something as a VAR param
without specific syntactical instructions to do so). I'm not sure which I
recommend - both have good and bad points. But since most Modula's allow you
to pass string constants where VAR ARRAY OF CHAR is expected, the standard
violation may have precedent. Should we vote?
Syntax is the hard part - perhaps this is why I've never submitted the idea.
FROM SYSTEM IMPORT ARGLIST;
(* VAR ARGLIST : POINTER TO ARRAY INTEGER OF ADDRESS;
*)
PROCEDURE printf(UNKNOWN);
VAR
formatStr : POINTER TO ARRAY INTEGER OF CHAR;
nextParm : INTEGER;
BEGIN
formatStr := ARGLIST^[0];
nextParm := 1;
. . .
(* as %? things are encountered in the format string,
* ARGLIST^[nextParm] is used to get the address of the
* data to output, and nextParm is incremented. The type of
* the params is known (or assumed) to be as dictated by the
* format string.
*)
END printf;
Note that ARGLIST is not a true variable - like most identifiers
imported from SYSTEM, it tells the compiler how to generate code
to do pseudo-real things.
This is incredibly easy to implement, since most
machines pass their parameters on the stack, and the address of the lowest
of them can be used as the value for pointer ARGLIST. This is what would
make it portable, barring machines that push parameters of different sizes
on the stack.
Purists will choke on all this, since it allows things to lose their type
without a specific type-cast. I can offer some small improvement:
FROM SYSTEM IMPORT ARGLIST;
(* VAR ARGLIST : POINTER TO ARRAY INTEGER OF ADDRESS;
*)
PROCEDURE printf(formatStr : ARRAY OF CHAR; UNKNOWN);
VAR
nextParm : INTEGER;
BEGIN
nextParm := 1;
. . .
(* this time formatStr is specified as a parameter; the compiler
* can therefore check at least that much of the call. Note
* that nextParm still starts at 1, since ARGLIST is not bound
* at all to the position of the UNKNOWN in the argument list;
* perhaps it should be. Vote?
*)
END printf;
Here, the UNKNOWN keyword is not the first thing in the list. All variables
before the UNKNOWN can be type-checked by the compiler; no variables may appear
*after* the UNKNOWN keyword.
This entire suggestion is meant to combat the possibility of Powell's compiler
setting some kind of standard: he has reintroduced Magic I/O in the form of
printf(), etc as built-ins. I agree with Powell that InOut is horrible and that
printf/scanf is good, type-free though it is. I disagree with the way he did
it: a programmer should be able to write his own general-purpose I/O stuff.
What if he prefer FORTRAN's FORMAT and WRITE statements to C's printf/scanf?
Help stamp out Magic I/O! Don't let the compiler accept syntax for its own
built-ins that you cannot duplicate in your own code (obvious exceptions are
SIZE(), TSIZE(), ORD(), etc - but these are low-level: I/O is not).
Is it too late to get this into the Modula-2 standard? Probably. With the
new NSC32 machine he's building, Wirth has changed the compiler enough to
demonstrate that standards are useless anyway. I am working on my own
compiler for my S-100 NSC32; I plan to implement some form of variable param
lists to procedures (probably the second of the two above). This will lead
to non-portable code, I know... But if the choice is between the hardly-ever
implemented InOut/Terminal/RealTerminal/etc, Powell's builtins, or something
non-portable but CLEAN.........
Can someone tell me how to send the above verbosity to some language or I/O
standards committee? I know it's too late, I just know it, but I have to try.
7-March-1986
Paul Vixie
{dual,hplabs,ptsfa,lll-crg}!well!vix