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!