bart@reed.UUCP (03/07/86)
> Here's a total flame. No > I strongly disagree that basic sequential I/O should go into a language. > Here at Xerox, could you have anticipated these I/O methods, or would > you like to change our compiler every time we prototype a better I/O > system (which we've done several times already, with new modules)? > > .... > .... I can't TAKE it any more!! It seems clear to me that the way it SHOULD have been done is for Modula-2 to have a generalized mechanism for letting users write 1) VARARGS (variable number of parameters) and 2) variable type of parameter routines. Then if one gets excited about not having "writeln", one can write a writeln library. And if one later gets windows, one can add an optional extra parameter to indicate a window number. Etc. The things that C, for example, didn't do right in this case were 1) Provide a standard mechanism for determining the type of an untyped parm. 2) Provide a standard way of counting and accessing each argument in a varargs list. Modula-2 open arrays suffer in that an open array is still a single parameter, which restricts the type of each of its elements, and that it isn't counted upon passing -- in short, they don't do what is wanted. Would it really have been that hard to do this right? Is it too late in the game to tack it on? Bart Massey ..tektronix!reed!bart
nagler%orb@SUN.ARPA (Rob Nagler) (03/09/86)
1) VARARGS (variable number of parameters) and
2) variable type of parameter
One should keep in mind that features add complexity and with
complexity cems size. Personally, I think there are far too
many unnecessary features in M2 already. For example, the CAP
function. It is nice, but is it necessary? Local modules are
cute, but do they really serve a purpose, that is, if it is a module,
why not slap a definition on it and make it a separate compilation unit?
The DEC and INC operators don't need to be in the language, they should
be optimized by the compiler or provided by a Assembly language module
So what does this have to do with over-loading? Well, I like M2 because
it runs on anything that has a processor and a little memory. Ada
on the other hand is obese with features ane of them overloading.
Granted, for certain applications it is much more convenient and
comfortable (like a Cadillac limo), but you have to consider what it
is like to use in environments which aren't ammenable to large
support systems (try driving in rural Italy sometime). Everything is
a tradeoff, but I can run a full implementation of M2 on an Apple //,
can't say the same for Ada.
A word about IO. You have to compare frequency with which a shorthand
notation is used, in order to justify its inclusion. The arithmetic
operators are an obvious example of a useful abbreviation. Var args
is a pretty serious feature to add and to add it for only one purpose,
condensed IO statements, is (I think) a weak argument. The number of lines
of IO statements in a module is usually much lower than, say, uses
of arithmetic operators. In general, most programs don't use complicated
IO features, e.g:
Enter a filename: farkle.mod
I haven't done a survey, but I bet the number of IO statements that
use more than argument is less than 5% of a program. I also find that
my IO statements which are very complicated end up being on multiple
lines, anyway. Therefore, it seems kind of wasteful to include a feature
which doesn't enhance the functionality and is probably not used all
that much.
Is it too late in the game to tack it on?
It's never too late, but I think it would be unwise.
Rob
PS. I hope those people who do not wish to hear my diatribes will
not be too greatly offended by my endless musings. I am VERY
interested in seeing M2 standardized and it is exactly these types
of issues which need to be resolved before standardization of
the language and library can occur.wyant@APOLLO.UUCP (Geoffrey Wyant) (03/10/86)
> I can't TAKE it any more!! It seems clear to me that the way it SHOULD have > been done is for Modula-2 to have a generalized mechanism for letting > users write > 1) VARARGS (variable number of parameters) and > 2) variable type of parameter > routines. Then if one gets excited about not having "writeln", one can > write a writeln library. And if one later gets windows, one can add an > optional extra parameter to indicate a window number. Etc. The things > that C, for example, didn't do right in this case were --------------------------------------------------------------------------------- Now, I can't take it any more ! I'm against modifying the language in general, and especially for adding features that reduce type-checkability. I think a "90 %" solution can be had with out modifying the language. DEFINITION MODULE FormattedWordIo ; EXPORT QUALIFIED Write2, Write6, Write10 ; PROCEDURE Write2(formatString: ARRAY OF CHAR; w1, w2: WORD) ; PROCEDURE Write6(formatString: ARRAY OF CHAR; w1, w2, w3, w4, w5, w6: WORD) ; PROCEDURE Write10(formatString: ARRAY OF CHAR; w1, w2, w3, w4,..., w10: WORD) ; END ; DEFINITION MODULE FormattedIObyAddr ; EXPORT QUALIFIED Write2, Write6, Write10 ; PROCEDURE Write2(formatString: ARRAY OF CHAR; a1, a2: ADDR) ; PROCEDURE Write6(formatString: ARRAY OF CHAR; a1, a2, a3, a4, a5, a6: ADDR) ; PROCEDURE Write10(formatString: ARRAY OF CHAR; a1, a2, a3, a4,..., a10: ADDR) ; END ; MODULE Foo ; .... FormattedWordIo.Write2("This is a word io example of %d lines and %d words", 1, 12) ; FormattedIoByAddr.Write6("Another crummy %a example of %d lines", adr(some_string), length(some_string), 1, NIL, NIL, NIL) ; END foo; I think you get the picture. Its not the most elegant solution in the world. But it does the job. How many times have you really needed an IO interface capable of handling an infinite number of parameters of heterogeneous types. If you really need that, cook up an IO interface that took a list, in which each entry had a type code, and either a word value or a pointer. Not every application needs variable length parameter lists, and you make everyone pay for it when you embed it in the language. Geoff Wyant -------
cdshaw%watdragon%waterloo.CSNET@CSNET-RELAY.ARPA (Chris Shaw) (03/13/86)
>Geoff Wyant > DEFINITION MODULE FormattedWordIo ; > > EXPORT QUALIFIED Write2, Write6, Write10 ; > > PROCEDURE Write2(formatString: ARRAY OF CHAR; > w1, w2: WORD) ; > PROCEDURE Write6(formatString: ARRAY OF CHAR; > w1, w2, w3, w4, w5, w6: WORD) ; > PROCEDURE Write10(formatString: ARRAY OF CHAR; > w1, w2, w3, w4,..., w10: WORD) ; > END ; Although this isn't the greaqtest, it keeps Modula-2 as is.. one thing that could be done (enter kludge mode) is to have the modula equivalent of the C preprocessor, which changes FormattedWordIo.Write( "% is equal %", x, y); to FormattedWordIo.Write2( "% is equal %", x, y); and FormattedWordIo.Write( "%, %, and % are less than %", w, x, y, z); to FormattedWordIo.Write4( "%, %, and % are less than %", w, x, y, z); That way, you satisfy the need for general I/O, and the requirement for type checking. Obviously, the M2 pre-processor would check number of % 's against number of args, and report an error. The disadvantage is the extra pre-process step. What do people think?? Chris Shaw watmath!watrose!cdshaw or cdshaw@watmath University of Waterloo He said... Bogus as HELL !!!