Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!mangoe
From: mangoe@mimsy.UUCP (Charley Wingate)
Newsgroups: comp.lang.misc
Subject: Re: Check the Arg Count
Message-ID: <4900@mimsy.UUCP>
Date: Thu, 1-Jan-87 23:10:06 EST
Article-I.D.: mimsy.4900
Posted: Thu Jan  1 23:10:06 1987
Date-Received: Fri, 2-Jan-87 03:39:36 EST
References: <3214@bu-cs.BU.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 73

Barry Shein writes:
[READ and WRITE in Pascal]
>[...] are not "system routines" in any useful sense of the word, they
>are built-ins specifically recognized (and handled) by the compiler.
>The fact that Pascal admits that such constructs are necessary yet
>does not allow any equivalent way for a programmer to write such code
>has always been damning in my mind (that is, you CANNOT provide read()
>or write() as your own pascal subroutines (not because of the names,
>call them myread() and mywrite() if you like.)

Well, they aren't admitted as necessary (in the orginal report).  They are
provided strictly as conveniences.  And in a teaching language environment
people don't write such routines often; when they do they should be forced
to do so in a disciplined manner.

>The C equivalent is a language feature available to the programmer,
>routines like printf() can and are written in C.

The varargs facility is a feature.  The implicit use of variable length
lists is a sloppiness (perhaps deliberate) which is exploited all over the
place.  Kernighan and Ritchie admit themselves that the original state of
affairs has gross defects.

> Perhaps [always running lint] should be an
>extension or option to CC commands but it's easy enough to implement
>on your own system with a shell script or by modifying the CC command
>(this is not equivalent to adding some major language feature or
>anything, you could "add" it by simply running lint by hand all the
>time, I am just suggesting that automating that and hiding it under
>the CC command would be trivial.)

You still haven't explained why lint as a processor should be logically and
functionally distinct from cc as a processor.  The ONLY reason I can see for
separating them is so that you don't have to be confronted with messages
telling you that you're writng tricky or otherwise dubious code.

>>Pascal, of course, takes a very extreme viewpoint on this.  Considering its
>>teaching language heritage, I find it hard to attack the decision that was
>>made.  Students need to learn to write diciplined programs before they go
>>out and break all the rules, and thus there's advantage to be had in making
>>those sort of restrictions syntactic requirements.

>I find this a weak justification. Students should learn to use things
>like lint etc.

No.  Students shouldn't HAVE to learn to use things like lint, in my
opinion, because they shouldn't have the option of NOT running things like
lint.

> You first posit that using variable argument lists is
>the definition of undisciplined and then proceed to use this axiom.

No.  What I insist upon is that variable length argument lists should be a
feature which is explicitly invoked, rather than the deliberate exploitation
of a sloppy point in the language, which is what C has now.

>I don't agree with the axiom. If a student can't remember to "line up"
>his/her arguments to routines then I have little hope for the student
>(yes, I do teach programming and have for several years, I think this
>kind of thinking has done more harm than good to students allowing
>instructors of mediocre quality [or intent] to evade giving the students
>what they really need, a decent working mental model of computation.)

Oh, come now.  Do you REALLY never ever make a careless mistake and forget
one of the arguments to a routine?  And why should this mistake be
syntactically equivalent to deliberately variable length argument lists?  It
seems to me that there's every advantage in the world to having the computer
catch stupid and careless errors wherever possible; I utterly fail to see
the advantage in deliberately maintaining a syntactic confusion between
mistakes and a "feature", especially when making the latter explicit makes
it vastly more obvious what the code really does.

CGW