Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!hao!cires!nbires!opus!rcd From: rcd@opus.UUCP (Dick Dunn) Newsgroups: net.lang.mod2 Subject: Re: Modula-2 I/O Message-ID: <845@opus.UUCP> Date: Thu, 27-Sep-84 19:36:18 EDT Article-I.D.: opus.845 Posted: Thu Sep 27 19:36:18 1984 Date-Received: Sun, 30-Sep-84 04:16:23 EDT References: <17@angband.UUCP> Distribution: net Organization: NBI,Inc, Boulder CO Lines: 25 A couple of comments on printf (or something like it) for Modula-2: In some sense, building a "real" formatting and I/O system for a language (if it's not built into the language) is a test of the power of the language. If you can't do it because the language won't let you express it in a reasonable fashion, that's a defect in the language that needs to be fixed. (I'm not saying that Modula-2 is deficient, only that you can apply this test.) However, keep in mind that the idea of a format string (as in C or FORTRAN) which is bound to the I/O list is NOT the only way to do it; in fact it's probably a poor way to go. It's very seldom that you need a variable format string and even less common to need the dynamic binding of I/O list elements to format elements. Pascal's approach shows a hint of a better way to go, although it comes out as a somewhat clunky special case and it has to be implemented specially by the compiler. ("Write" in Pascal is NOT a procedure, no matter what you say:-) Anyway, if you bind format elements to (input) variables or (output) expressions at compilation time, you can get much-needed type checking. A general mechanism here would have much wider applicability than just I/O. In fact, the main problem isn't really an I/O problem anyway--it has to do with control over the formatting that happens before the I/O. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Cerebus for dictator!