mangoe@mimsy.UUCP (Charley Wingate) (12/30/86)
Mike Eager writes: >One should note that Lint does several things which are not done by the >C compiler, shouldn't be done by the compiler, and which are not strictly >related to the language. One of these is verifing the matching of the >number of arguments between the caller and callee. Other is reference/ >lack of reference to globals. Oh? In case you hadn't heard, compilers are not COMPELLED to allow variable length argument lists in most languages. My personal opinion is that they ought to be expressly forbidden unless there is some syntax that makes it quite clear what is going on. In a single compilation, after all, this is a static property of the code anyway; you may want to argue that it shouldn't cause the compiler to bomb (and I may even agree with you, grudgingly), but I don't see the point of never checking for it at all. The latter comments also pertain to the references to globals, too. Many installations have paper rules about not having any warning messages in compiled code. I cynically observe that the lint/cc separation has the advantage that the compiler generates no warning messages at all-- at least, it's an advantage to the writers of "tricky" code. C. Wingate
rgenter@Diamond.BBN.COM (Rick Genter) (12/30/86)
In article <4886@mimsy.UUCP>, mangoe@mimsy.UUCP (Charley Wingate) writes: > Mike Eager writes: > > [ stuff about how lint checks for things that ccom doesn't ] > > In case you hadn't heard, compilers are not COMPELLED to allow variable > length argument lists in most languages. My personal opinion is that they > ought to be expressly forbidden unless there is some syntax that makes it > quite clear what is going on. In a single compilation, after all, this is a > static property of the code anyway (1) Bullshit. Variable length argument lists are part of C. C compilers are COMPELLED to allow variable length argument lists. Mike was referring to C. (2) Bullshit. How do you deal with printf(), scanf(), etc.? In a single compilation, it is a static property of the code that these routines need to be called with variable numbers of arguments at different points within the same program (or even the same routine). The point Mike was trying to make (I believe) is that, at least for C, there are syntax checkers (i.e., compilers) and style checkers (i.e., lint). Many languages try to define the style as part of the syntax of the language. Feh. One of the nice concepts encompassed by lint is that you can tell it that you are intentionally breaking the style "rules" (I'll readily agree that the implementation of these concepts is pretty piss poor). Try doing that in Pascal or Ada. > C. Wingate - Rick -- Rick Genter BBN Laboratories Inc. (617) 497-3848 10 Moulton St. 6/512 rgenter@bbn.COM (Internet new) Cambridge, MA 02238 rgenter@bbnj.ARPA (Internet old) seismo!bbn.com!rgenter (UUCP)
jef@charming.uucp (Jef Poskanzer) (12/31/86)
In article <3101@diamond.Diamond.BBN.COM> rgenter@Diamond.BBN.COM (Rick Genter) writes: >(1) Bullshit. Variable length argument lists are part of C. C compilers > are COMPELLED to allow variable length argument lists. Mike was referring > to C. > >(2) Bullshit. How do you deal with printf(), scanf(), etc.? In a single > compilation, it is a static property of the code that these routines > need to be called with variable numbers of arguments at different points > within the same program (or even the same routine). (1) Bullshit. Variable length argument lists are a very very small part of C, but to accomodate them cc and lint throw out 90% of the useful type checking that better languages do. For example, try running the appended program through lint. I will be amazed if anyone has a lint that complains about it. In Mesa, it is very common to do this kind of call-back programming, and the compiler catches errors of this type. (2) Bullshit. I found it very easy to write a printf-clone in Mesa. I used variant records for the data, so that the compiler did most of the type-checking work, and I got variable numbers of arguments by using defaulting parameters. No problem at all for a Real Man's Language. Besides, even if you naively believe that lint does a good job of type-checking, the fact is that most people simply don't use it. In fact, over half of the systems I program on don't even have lint installed, and if I were to complain to the sysadmin, he'd tell me they can't afford the space. Separating type-checking out of the compiler is an engraved invitation for bogosity. --- Jef Jef Poskanzer unisoft!jef@ucbvax.Berkeley.Edu ...ucbvax!unisoft!jef (415)644-1230 - - - - - - - - - - % cat test.c #include <stdio.h> int intfunc( intarg ) int intarg; { return ( 10 / intarg ); } int floatfunc( floatarg ) float floatarg; { return ( (int) ( 10.0 / floatarg ) ); } int callit( func ) int (*func)( ); { return( (*func)( 2 ) ); } main( ) { printf( "callit( intfunc ) = %d\n", callit( intfunc ) ); printf( "callit( floatfunc ) = %d\n", callit( floatfunc ) ); } % cc test.c -o test % lint test.c test.c: % ./test callit( intfunc ) = 5 Floating exception
sierchio@milano.UUCP (12/31/86)
Hey, fella. Bullshit doesn't add weight to your argument. for your info, printf() and scanf() may not even be functions. They are frequently implemented as macros, and are part of stdio. NOW -- frequently compilers don't do arg count checking. What this means is that at execution time, when a fn is called with an arg list, as in: foo(a, b, c) a, b, and c are pushed onto the Frame, or Stack, or Heap (as you like). if foo() is defined as: foo(a,b) int a, b; then it will only reference a and b. However, c is there, and it's available as *((&b)++). (well, probably) It still ain't LISP, fella. -- Michael Sierchio @ MCC Software Technology Program UUCP: ut-sally!im4u!milano!sierchio ARPA: sierchio@mcc.ARPA THE OPINIONS EXPRESSED AREN'T NECESSARILY.
ken@rochester.ARPA (SKY) (12/31/86)
|for your info, printf() and scanf() may not even be functions. They are |frequently implemented as macros, and are part of stdio. I suggest you look again at stdio.h. All the cpp's I know don't allow variable numbers of arguments to a macro. You're confusing them with putchar and friends. As for the main discussion: There are two issues that are in danger of being confused here - separate compilation and varargs. It just so happens that vanilla Pascal disallows both and C is the reverse. Separate compilation: with the problem of writing large software packages, it is generally (but not universally) considered a good thing to have cross-module checking. C's checking (a.k.a. lint) is voluntary, Modula-2's is mandatory. Varargs: there have been several proposals for the specification syntax of varargs. I would be interested if any real language has implemented one. If you would rather debate religious issues, followup to misc.religion.langs (a.k.a. /dev/null on most systems :-)). Ken
mangoe@mimsy.UUCP (Charley Wingate) (01/01/87)
Rick Genter writes all sorts of flamy things about C and lint and arg count checking. In his haste he makes a pile of errors. First off, he erroneously implied that I claimed that there should be no variable length argument lists. What I actually said was that the declaration syntax should make it obvious that variable length arg lists are permissible. Perhaps the ANSI C committee is composed entirely of morons, but I have been informed by one of the members that the ANSI standard is in fact going to have a portable method for dealing with variable argument lists which will make just the sort of requirement I want to see. I also note that in fact Pascal for one HAS variable argument lists-- for certain system routines such as READ and WRITE. SO does FORTRAN (MAX and MIN are examples). In C by contrast the current mechanism is terribly defective, as Kernighan and Richie point out (p. 71). For example, it is impossible to write a general MAX routine that takes and indefinitely large number of integers, unless you explicitly tell it how many values to look for. I fail to see the advantage in having separate style and syntax checkers. In COBOL, for instance, you will find that most compilers go to a lot of trouble to tell you that "this looks supicious". THe same is true of FORTRAN. THe only "advantage" I see to separating the two functions is that it's easier to justify an undiciplined, tricky coding style because you are constantly confronted by the compiler's disapproving messages. I cannot at all see any defense for allowing the use of variable argument lists to remain implicit in the program; it's undiciplined and leads to needless errors. 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. (ADA I won't comment on because I don't know the syntax well enough.) C. Wingate
cjl@iuvax.UUCP (01/01/87)
>>(1) Bullshit. Variable length argument lists are part of C. C compilers >>(2) Bullshit. How do you deal with printf(), scanf(), etc.? In a single >(1) Bullshit. Variable length argument lists are a very very small part >(2) Bullshit. I found it very easy to write a printf-clone in Mesa. Do we have to use these words for discussion ? How about extending lint to flag them as possible errors ? P.S. > Hey, fella. Bullshit doesn't add weight to your argument.
ron@brl-sem.ARPA (Ron Natalie <ron>) (01/02/87)
You are wrong. Variable length argument lists are not compelled to work in C. In fact, they frequently don't. That's why we have varargs, which fudges a variable number of arguments in a fixed calling sequence. Printf just happens to get lucky (and frequently is not written in "C" either). -Ron
bzs@bu-cs.BU.EDU (Barry Shein) (01/02/87)
From: mangoe@mimsy.UUCP (Charley Wingate) >I also note that in fact Pascal for one HAS variable argument lists-- for >certain system routines such as READ and WRITE. SO does FORTRAN (MAX and >MIN are examples). These 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.) Of course, I am attempting to speak within some context of standard pascal, a retort that there exists something which calls itself a pascal compiler and even seems to accept some pascal code which also allows this is a futile argument. The C equivalent is a language feature available to the programmer, routines like printf() can and are written in C. Thus, the analogy fails. C attempts to solve a much harder problem. >I fail to see the advantage in having separate style and syntax checkers. I fail to see the distinction. Code is code. Do you also demand that all your compilers have all their other functions (pre-processing, lexical analysis, syntax checking, code generation, assembly, link editing) in one module? Of course not, your only complaint is perhaps with the 'cc' command which runs the various passes automatically but does not run lint as you would like. Perhaps that 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.) >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. You first posit that using variable argument lists is the definition of undisciplined and then proceed to use this axiom. 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.) Well, at least you admit its teaching heritage, unfortunately there are more than a few folks out there using pascal for more than just teaching. -Barry Shein, Boston University
mangoe@mimsy.UUCP (Charley Wingate) (01/02/87)
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
chris@mimsy.UUCP (Chris Torek) (01/02/87)
In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes: >Barry Shein writes: >>Perhaps [always running lint] should be an extension or option to >>CC commands ... >You still haven't explained why lint as a processor should be logically and >functionally distinct from cc as a processor. What is this, a flame war? Charley, I know you are capable of thinking of this one yourself. How about the *time* it takes to run lint? Remember, you are not compiling on a top-of-the-line Amdahl, but a poor little PDP-11 shared by sixteen other users. It takes 15 minutes to recompile your program after a one line change in a header file. A full lint-style check would extend that to 30 minutes. (Yes, this argument breaks down rapidly when you are running on a top-of-the-line Amdahl . . . unless you pay for CPU time. The point is that this is a historic artifact, yet still, I think, useful---in the right hands.) >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. No, separating them gives YOU the *option* of deciding whether to expend computer time checking for tricky or otherwise dubious code. I work on a poor little Vax 11/750 much of the time, and I run lint, but sparingly. I have that choice, and often I am glad of it. (I *still* wish the compiler were faster, even after Donn Seeley and I sped it up by 25%, and even though I ship compiles over the Ethernet to the 8600.) >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. This may well be true. On the other hand, I wonder if these students will have any idea what happens in `real world' FORTRAN programs after they graduate. It is a tradeoff: Confuse them now, or confuse them later? (The proper time is `as soon as they can handle it', which is quite difficult to determine---but at this university, likely later than sooner. [Note that a BS in CS is still considered a Trade School diploma, at least by all the employers around here. Some think this sorry state of affairs, but that is not a matter to discuss in this newsgroup. <Can I really head off flame wars this way?>]) >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? I do, but lint catches them. That is one of the reasons I use it. (Not only that, but it has become natural for me to type /* VARARGS */ or /* ARGSUSED */ in front of functions that have variable argument lists, or sometimes do not use some arguments. Others, watching me code, have mentioned that I am just warped. :-) I would not, though, object to a source syntax for variable length argument lists, as opposed to this rather odd commentary syntax.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
faustus@ucbcad.berkeley.edu (Wayne A. Christopher) (01/02/87)
In article <4900@mimsy.UUCP>, mangoe@mimsy.UUCP (Charley Wingate) writes: > 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. Most of the things lint points out either aren't available to ccom, or are definitely not appropriate. How is ccom going to know what is in the other files that I'm going to link with? Detection of incompatible arguments, return values, etc across modules is lint's most useful function. Also, so you really want ccom to tell you that you haven't used some of the variables you declare? Then there are things that are technically portability problems, but are unavoidable -- for instance, when I assign a long to an int, lint will complain about it, but if I can't change the types of the variables and I know that the magnitude of the long will be <= the magnitude of a short, I'll just put #ifndef LINT around that statement and get rid of the warnings. If ccom complained about it I couldn't do that. Wayne
bzs@bu-cs.BU.EDU (Barry Shein) (01/03/87)
From: mangoe@mimsy.UUCP (Charley Wingate) >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. Lint goes further than that really. One nice thing about the arrangement is that it can warn you of things that are not "tricky or dubious". For example, non-portable constructs (it's not irrational to write a non-portable program, it happens legitimately, or perhaps something that will only be made portable via different link libraries.) I remember PL/1 was full of "warnings" and "informational" messages, to the point that the programmers I worked with simply ignored them (oftentimes disasterously.) You have to draw a line, running lint every so often as a double-check is a real plus (in my opinion.) I get the msgs when I want them (of course, I also remember that PL/1 had both a checkout and optimizing compiler, unfortunately that was a real mess, like it wasn't uncommon that they refused to compile the same programs.) >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. I repeat, setting up an environment to force them to use lint is trivial. At least you get the choice, and if you have to run on an overloaded machine you can take your chances that they will run lint voluntarily, perhaps not on every little edit fix, but often enough (I am dubious that people who will resist "doing the right thing" are going anywhere anyhow, at least right now, maybe they'll mature.) Does your opinion extend to the following: Makefiles: Surely this is at least as good a practice as running lint. Make dependancy scripts: again... Separate source compilation: oops, can't even do this in standard Pascal in any rational way, oh well... Using library routines rather than treating programming as an ad hoc exercise: oops again, as I've said before you need one strlen routine for every length of string in pascal, can't write a generalized sort routine either, gotta ad hoc that also, same for I/O routines and anything else that might benefit from being written once by an expert rather than hacked together for every new program because you can't get around the "strong" typing. Why do I drag all this in? Because I am utterly convinced that this entire mindset of forcing the user to be what s/he isn't (careful, conscientous etc) is an utter failure. You want a good program? Hire a good programmer. You want to become a good programmer? Ya gotta work at it. Sorry, ain't no short cuts. The solution is not to put more restrictions in programming languages in an attempt to control the incompetent at the expense of the competent. The solution is to teach good design. Design involves choices and rules, not removing all the sharp knives from the woodshop for fear that some turkey will come in and cut him/herself. Unfortunately, Pascal makes a false promise it has never been able to keep. In fact, it and its successors (at least as of this date) have been by and large a failure in practice. Very little code of any use has ever been written in them. This is due to the very poor design inherent in these. It is not surprising they appeal to those who discount careful design and effort as being the ultimate goal. In short, the "emperor" has no clothes. -Barry Shein, Boston University
mark@cogent.UUCP (Mark Steven Jeghers) (01/05/87)
In article <120900001@iuvax> cjl@iuvax.UUCP writes: > > >>>(1) Bullshit. Variable length argument lists are part of C. C compilers >>>(2) Bullshit. How do you deal with printf(), scanf(), etc.? In a single > >>(1) Bullshit. Variable length argument lists are a very very small part >>(2) Bullshit. I found it very easy to write a printf-clone in Mesa. > > Do we have to use these words for discussion ? > How about extending lint to flag them as possible errors ? > >P.S. > Hey, fella. Bullshit doesn't add weight to your argument. It only adds bullshit to your argument. :-) -- +----------------------------------------------------------------------------+ | Mark Steven Jeghers ECHOMPGULP - process has eaten it | | cryptography, terrorist, DES, drugs, cipher, secret, decode, NSA, CIA, NRO | | | | {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark | | | | Cogent Software Solutions can not be held responsible for anything said | | by the above person since they have no control over him in the first place | +----------------------------------------------------------------------------+
jef@charming.uucp (Jef Poskanzer) (01/06/87)
[In response to my article, I received the following e-mail message. Unfortunately, some host, probably amdahl, munged the path, so I can't reply to it. (There is no user "mdash" on amdahl.) Since the subject is within the bounds of newsgroup discussion, I am taking the liberty of replying via news.] >Date: Wed, 31 Dec 86 07:59:00 EST >From: lll-lcc!seismo!amdahl!mdash (45415-M.D.Scheer(mhB624)mhB624) >Message-Id: <8612311259.AA06480@amdahl> >To: jef@unisoft >Subject: Re: Check the Arg Count >Newsgroups: comp.lang.misc >Organization: AT&T Information Systems, Summit, N. J. > >>(2) Bullshit. I found it very easy to write a printf-clone in Mesa. >>I used variant records for the data, so that the compiler did most >>of the type-checking work, and I got variable numbers of arguments >>by using defaulting parameters. No problem at all for a Real Man's >>Language. > >Interesting. I am only passingly familiar with Mesa, but have worked >extensively with Ada (Let's omit the scatological comments for the >moment), and have concluded that one cannot duplicate the flexibility >of printf in Ada without either escaping from type-checking. How did >you avoid an exhaustive listing of all permitted argument combinations >in your variant record type definition? How bad is the data space over- >head of you implementation? The way it worked is that each data item was a separate variant record, so I didn't have to list "all permitted argument combinations" - just all the different types that could be formatted. A sample call: PF.Put["line number = %g, line = \"%g\"\n"L, card[linnum], str[line]]; The card[...] and str[...] are record constructors. (Actually, they are inline procedures that return discriminated variant records. A true record constructor would have another set of [] around it. Probably the compiler could be made smart enough so that you could just use the variable name without any [] bullstuff, but currently it's not.) The %g means "general" - since the type of the data item is known already, there is no need to specify it in the format string. As for data space overhead - by the only measure that matters, it's negative. When I wrote this package, I converted a few system utilities to use it. The size of the compiled binaries decreased by up to 30%. --- Jef Jef Poskanzer unisoft!jef@ucbvax.Berkeley.Edu ...ucbvax!unisoft!jef (415)644-1230
brett@wjvax.UUCP (Brett Galloway) (01/06/87)
In article <1193@ucbcad.berkeley.edu> faustus@ucbcad.berkeley.edu (Wayne A. Christopher) writes: >In article <4900@mimsy.UUCP>, mangoe@mimsy.UUCP (Charley Wingate) writes: >> 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. > >Most of the things lint points out either aren't available to ccom, or >are definitely not appropriate. How is ccom going to know what is in >the other files that I'm going to link with? Detection of incompatible >arguments, return values, etc across modules is lint's most useful >function. Wayne's first point is the strongest -- ccom CAN'T know anything about source files outside of the one at hand. Lint can. I do, however, have a gripe about lint (at least about 4.2bsd lint). It provides the ability to create lint libraries. Unfortunately, lint treats these libraries differently than cc treats object libraries. It would be most useful for maintaining large pieces of software if lint behaved the same as cc -- lint'ing source files into some intermediate form, finding all lint errors unique to that source file (this is analogous to the compile cycle), and lint'ing the intermediate lint files together to find global errors (this is analogous to the load cycle). This would make lint easier to use, especially from within makefiles. If lint were easier to use, it might be used more extensively. -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
sommar@enea.UUCP (Erland Sommarskog) (01/07/87)
In article <23508@rochester.ARPA> ken@rochester.UUCP (SKY) writes: > >Varargs: there have been several proposals for the specification syntax >of varargs. I would be interested if any real language has implemented >one. Well, VAX-pascal has something like that. If you declare: PROCEDURE Alice( Param1 : A_type; (. List .) Varargs : Some_other_type); You can call Alice with for instance: Alice(A_type_value, Some_other_type_value1, Some_other_type_value2, ... etc if you like); VAX-pascal offers you standard routines to find out many you really did provide. The restriction is that Varargs must be the last parameter and of course all must of the same type as far as I can see. I never used this feature myself. (If any one wonders: VAX-pascal is quite a large language which happen to standard pascal as a true subset.) Ada does not allow this, however I think that array aggregates would fit extremely well for the purpose. If you want a general Max routine you declare: TYPE Element_array IS ARRAY (<> RANGE integer) OF Your_favourite_type; PROCEDURE Max(Elements : Element_array) IS...END Max; and then you call Max_value := Max((1,2,3)); To comment the debate in general I must I don't understand it. Saying that a C compiler shouldn't check for correct numbers of procedure parameters, just because printf() and scanf() accepts variable parameters lists makes no sense. These are standard routines aren't they? Thus the compiler do recognize them.
sommar@enea.UUCP (Erland Sommarskog) (01/08/87)
In article <3226@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >Why do I drag all this in? Because I am utterly convinced that this >entire mindset of forcing the user to be what s/he isn't (careful, >conscientous etc) is an utter failure. You want a good program? Hire >a good programmer. You want to become a good programmer? Ya gotta >work at it. Sorry, ain't no short cuts. > >The solution is not to put more restrictions in programming languages >in an attempt to control the incompetent at the expense of the >competent. The solution is to teach good design. Design involves >choices and rules, not removing all the sharp knives from the woodshop >for fear that some turkey will come in and cut him/herself. > >Unfortunately, Pascal makes a false promise it has never been able to >keep. In fact, it and its successors (at least as of this date) have >been by and large a failure in practice. Very little code of any use >has ever been written in them. This is due to the very poor design >inherent in these. It is not surprising they appeal to those who >discount careful design and effort as being the ultimate goal. In >short, the "emperor" has no clothes. Well, I may missunderstand what you mean, but to me it seems that you are trying to say that type-checking languages like Pascal, Ada etc are inferior to languages that are more relaxed at this point, like C. Also you seem to imply that type checking is only for bad programmers. I happen to consider myself as quite a good programmer, and I think checking of all possible kinds is compulsary. The more the compiler checks for me the less errors I have to search for when I test. As I said my program- mings skills are good - still my own opinion - but unfortunately I make a lot of carless mistakes. Take this example: (in Pascal) PROCERDURE Modify(a : integer); a := 2*a; END; The compiler will accept this, but of course it won't work since I forgot the "var". In Ada this is not possible. If I don't write anything "a" will a in-parameter. In-parameters are constants in Ada so the compiler will not allow me to modify it. If I make "a" an out-parameter, I can't read from it. The only possible way is in-out. Or do you think that I'm bad at design just because I make these mistakes? Actually, I can't escape the feeling that the people who advocates relaxed checks are those who are bad at good design. The more of tricks you put into it, the harder to understand it is. A good programmer don't feel restricted by a checking compiler, he feels supported. Finally, one note a bout Pascal since you mention this language. As we all know, Pascal was never ment for "productive" programming, just for education. On the other hand, the most compilers do offer extentions for separate compilation, string handling etc. Of course these extentions doesn't make Pascal very portable. By the way, as far as I know the most of TeX is written in standard Pascal, but you perhaps would call that useless software?
putnam@steinmetz.UUCP (01/08/87)
In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes: >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. I dont want to get into a "to lint or not to lint" fight here, but i do think that there are very good reasons to keep lint separate from cc : In a large system, lint looks at everything, and in "edit-run-think-debug..." loops, the overhead of lint is unnecessary and unhelpful. (I change a loop from "for (i=0 ; i < 100 ; i++)" to "for (i=0 ; i < 101 ; i++)", and need to re-lint the file. Absurd. I might be building something that produces C code as output, and linting it will be expensive, and will require that i build in the annotations to keep lint happy as i build the processor. This will interfere with my concentrating on the important structure of the program. I (or the people i work for) might have a modified lint with strong stylistic guidelines, or... which should be run instead. In general, i believe that it is a good idea to keep things which are logically separate, separate. Thus, i like having a c compiler which keeps the preprocessor, the compiler, the assembler, .... all distinct. In this way i can change a processor that does that step when i need to, omit steps (where that makes sense), or add additional steps (like editing the assembler). Most of the time, i do not do this, but i have needed to in the past, and found difficulties with compilers that would not let me get to intermediate stages. (I needed to get at the assembler output to do something once, and the only way to do it was to use the flag that produced an assembler listing (interleaved with the code, and the results of the assembly!), then edit the listing to produce usable assembler - and that didnt even assemble correctly without more work.) Keep separate parts separate! Wasnt this part of the "Unix(tm) Philosophy"? -- O -- jefu tell me all about -- UUCP: steinmetz!putnam Anna Livia! I want to hear all.... -- ARPA: putnam@GE-CRD
holloway@drivax.UUCP (Bruce Holloway) (01/09/87)
In article <1635@enea.UUCP> sommar@enea.UUCP (Erland Sommarskog) writes: >Well, I may missunderstand what you mean, but to me it seems that you are >trying to say that type-checking languages like Pascal, Ada etc are inferior >to languages that are more relaxed at this point, like C. Also you seem >to imply that type checking is only for bad programmers. Let the compiler do the type checking... so long as it stays there. Pascal puts in a lot of code for array overruns, etc., that are unnecessary for a well-designed program. You could turn all this off on the Pascal I learned on, which made it tolerable. But I don't want anything in the program I didn't put there -- if I'd wanted subscript checking, I would have added it. -- ....!ucbvax!hplabs!amdahl!drivax!holloway "What do you mean, 'almost dead'?" "Well, when you stop breathing, and moving around, and seeing things... that kind of almost dead."
bzs@bu-cs.BU.EDU (Barry Shein) (01/10/87)
From: sommar@enea.UUCP (Erland Sommarskog) >Well, I may missunderstand what you mean, but to me it seems that you are >trying to say that type-checking languages like Pascal, Ada etc are inferior >to languages that are more relaxed at this point, like C. Also you seem >to imply that type checking is only for bad programmers. Perhaps its semantics. You call it type-checking. I'll call it type-obsession. When type-checking becomes so strong as to make it impossible to write a general purpose sort() subroutine or string handling library then yes, it is type-checking gone mad. It reminds me of a rather novice programmer I once worked with. Her previous job was as an assembler programmer on a machine that had no multiply instruction. She told me the first thing every new programmer there had to do was write a multiply subroutine for themselves. Think about it, every piece of software coming out of that company had a different multiply routine packaged in it. I don't see things as much different in the Pascal world. Software just isn't re-useable. >Actually, I can't escape the feeling that the people who advocates >relaxed checks are those who are bad at good design. The more of tricks you put >into it, the harder to understand it is. A good programmer don't feel >restricted by a checking compiler, he feels supported. Do you think writing a sort routine or string package once and reusing it a 'trick'? How about a math library? >Finally, one note a bout Pascal since you mention this language. As we all >know, Pascal was never ment for "productive" programming, just for >education. On the other hand, the most compilers do offer extentions >for separate compilation, string handling etc. Of course these extentions >doesn't make Pascal very portable. By the way, as far as I know the most >of TeX is written in standard Pascal, but you perhaps would call that >useless software? First, I think it was a mistake using a non-productive language (to use your phrase) for education. The leap from beginner to a person with certain views about the programming milieu happens far too fast to allow it to happen in such an artificial environment. The damage is obvious, we have people wandering the streets trying to do useful work in Pascal because that's what they were taught. The notion of extensions just makes it worse. It convinces the student that the computer field is a random collection of unintelligible hacks as textbooks don't match the language at hand nor manuals etc. Have you ever tried to explain to a student why the example he or she typed in from their textbook won't work without a major rewrite at the language level (bad enough if there's some O/S interface, but at the language level?) I have, they look at you like you're a snake oil salesman and I don't blame em. As to TeX, I know, it seems to be the only program ever written in standard pascal so everyone points it out when these things come up: 1. It's not really written in Pascal, it's written in WEB, Pascal is it's assembly language. In the same sense that a good HLL can make the fact that it's assembly language is assembly language fairly transparent, so can WEB. I mean, I can probably manage to write a compiler to turn my favorite HLL into Pascal if I had to, would that mean my programs were really in Pascal? Is Pascal really machine language because that's what it's translated to? 2. Have you ever actually looked at TeX, or better, tried to change something in the TeX source code? Try it, if you don't get sick you have a far stronger constitution than I do. 3. TeX is utterly standalone on purpose so it obviates any need for standard subroutine packages. Of course, the whole change file facility that had to be implemented leaves one only wondering about whether there was a rather large fundamental problem remaining to be solved. 4. In fact, the model of TeX is so simple it could be written in most any language. It takes an input stream of characters, classifies them (possibly into tokens) and transforms them into an output stream. I am not saying the details of this are simple, but I am saying that to do so it's not surprising that any language with a few simple operators was powerful enough for the job. It also has no need for any external standards (for example, a standard math package) as it defines its own standards. The only interface with the outside world it has is that it is able to read streams of chars and transform them to other streams of 'chars' (actually, a dvi file, but similar enough it's not worth beleaguring that point.) Of course, it has to be able to open files by name but then again that's exactly the part that has to be redone every time TeX is 'ported', it's a moot point. If you think TeX is the shape of the future of software engineering than god help us all... -Barry Shein, Boston University
spf@clyde.UUCP (01/10/87)
Building on a followup by sommar@enea.UUCP (Erland Sommarskog): > >In article <3226@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >>The solution is not to put more restrictions in programming languages >>in an attempt to control the incompetent at the expense of the >>competent. Who said we were trying to control the incompetent? You know, I wear boots when I use my axe, even though I have a lot of experience with axes. I like to protect myself against mishaps. >> The solution is to teach good design. This is a very funny argument; a "good design" will be largely independent of language. The more powerful (i.e. permissive) the language, the weaker its compiler. The "highness" of a language determines the strength of its compiler, and deals primarily with PROGRAMMING, not DESIGN. The fact that I typed = when I meant == in C is NOT a design issue, it's a programming issue. >> Design involves >>choices and rules, not removing all the sharp knives from the woodshop >>for fear that some turkey will come in and cut him/herself. Even the "competent" wordworker wears safety glasses. >> >>Unfortunately, Pascal makes a false promise it has never been able to >>keep. In fact, it and its successors (at least as of this date) have >>been by and large a failure in practice. Very little code of any use >>has ever been written in them. Got Data? I've done a lot of real-time image-processing code in Pascal (perhaps 100,000 lines of source delivered), and wonder how much of a failure it was. I don't claim Pascal is the Platonic programming language; there is no such thing. But more often than not it's my language of choice, because it will allow me to do the job more quickly, and with fewer errors, than the other contenders. I've had great success with Pascal programs which call occasional assembly language or C routines when low-level machine access is required. >Well, I may missunderstand what you mean, but to me it seems that you are >trying to say that type-checking languages like Pascal, Ada etc are inferior >to languages that are more relaxed at this point, like C. Also you seem >to imply that type checking is only for bad programmers. That's what I read from the argument too. And that's precisely the opposite of my opinion. My rule is "Use the highest level language which will do the job, because that brings the most powerful compilation tool to bear and reduces the number of errors which hit run-time. The egos of a lot of programmers cause them to miss an important point: beyond a fairly short start-up, a programmer's error rate does not substantially decline as a function of experience. This is partly due to psychological learning issues, and partly because task load often increases with experience, with reduced attention masking any improvement in the error rate. >Or do you think that I'm bad at design just because I make these mistakes? >Actually, I can't escape the feeling that the people who advocates >relaxed checks are those who are bad at good design. The more of tricks you put >into it, the harder to understand it is. A good programmer don't feel >restricted by a checking compiler, he feels supported. Right-on. I regard programming as a means to an end, and thus take an "engineering" point of view (as opposed to a "for the fun of it" point of view). When I write a program (even for my own use only) I want to minimize the amount of time I have to spend scrutinizing the code (let a strong compiler do that), and maximize the likelihood that I'll be able to read and understand the program a year or more later. This is even more important when developing software for others. Since there is an inverse relationship between the power of the language (i.e. what it lets me do) and the strength of the compiler (i.e. what mistakes it won't let go by), I choose the WEAKEST language that will still do the job, and thus use the most POWERFUL compiler I can. Remember, fans, even K&H assert that C is only a "relatively low level language" ["The C Programming Language", Kernighan and Ritchie, Prentice-Hall 1978]. Is it a powerful language? YES (and fun, if that's what you want)! Does it have a strong compiler? NO, it can't! So many things are legal in C that erroneous code often goes by, because it looks like some other legal construct. Steve Frysinger **** Remember what the doormouse said: "Feed your head!" -- Jefferson Airplane
faustus@ucbcad.berkeley.edu (Wayne A. Christopher) (01/11/87)
Be careful when you use terms like "high level" and "strong typing". Just because a language is called by some people "strongly typed" by some people doesn't mean much. Pure Pascal, which doesn't even let you write a function to manipulate strings without knowing their lengths, is strongly typed by some definitions (and a good example of why by those definitions strong typing is a bad thing), but is not strongly typed by other definitions because you can convert values from one type to another with unions. Sure, argument checking is good, but if you take the philosophy a bit further and eliminate anything like casts you have made the language useless. You have to be able to protect the user against inadvertent errors without preventing him from doing just about anything he wants when he really wants to... Wayne
mouse@mcgill-vision.UUCP (der Mouse) (01/11/87)
In article <1634@enea.UUCP>, sommar@enea.UUCP (Erland Sommarskog) writes: > To comment the debate in general I must I don't understand it. > Saying that a C compiler shouldn't check for correct numbers of > procedure parameters, just because printf() and scanf() accepts > variable parameters lists makes no sense. These are standard > routines aren't they? Thus the compiler do recognize them. NO. The compiler does not treat scanf(), printf(), etc, any differently from any routine which is defined in another file. They are "standard" only in that (almost) all environments which support C also support these routines. Pascal, on the other hand, does things for write(), writeln(), etc, differently from the way it handles calls to user routines. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu
debray@megaron.UUCP (01/12/87)
Barry Shein: > From: sommar@enea.UUCP (Erland Sommarskog) >> [ ... ] Also you seem to imply that type checking is only for bad >> programmers. > > Perhaps its semantics. You call it type-checking. I'll call it > type-obsession. When type-checking becomes so strong as to make it > impossible to write a general purpose sort() subroutine or string > handling library then yes, it is type-checking gone mad. What you want is a Milner-style polymorphic type system. There _are_ reasonable notions of what constitutes a "type" out there, even if Pascal doesn't have them. -- Saumya Debray University of Arizona, Tucson debray@arizona.edu {allegra, cmcl2, ihnp4}!arizona!debray
sommar@enea.UUCP (Erland Sommarskog) (01/13/87)
In article <594@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <1634@enea.UUCP>, sommar@enea.UUCP (Erland Sommarskog) writes: >> To comment the debate in general I must I don't understand it. >> Saying that a C compiler shouldn't check for correct numbers of >> procedure parameters, just because printf() and scanf() accepts >> variable parameters lists makes no sense. These are standard >> routines aren't they? Thus the compiler do recognize them. > >NO. The compiler does not treat scanf(), printf(), etc, any >differently from any routine which is defined in another file. They >are "standard" only in that (almost) all environments which support C >also support these routines. Pascal, on the other hand, does things >for write(), writeln(), etc, differently from the way it handles calls >to user routines. There's been some people telling me same thing by mail. And, OK, I was wrong in my statement that a C compiler recognizes the standard routines. But on the other hand I never meant to claim that as a fact, but merely that the compiler COULD (and should) recognize them. It is completely possible to put that in the compiler, isn't it. The question whether the fact that no existing C compiler actually does this means that all compilers are stupid or that there is an error in the language defition is more of semantical nature which I am not going to discuss. To get I/O-routines (or whatever scanf() is) with variable parameter lists, there seems to be four ways: 1) Make them standard routines recognized by the compiler. The best alter- native. Specially in a small langauge like C. 2) Introduce a syntax that allows this. Possible, but not very attrcative. 3) Skip checking of parameter count. To be straight: Ridiculous. 4) Forget the whole thing. If anyone has any more objections against me at this particular point which are directly related to C, I think he may as well keep them for himself. I'd like to regard this as a general debate, not as a particular C issue.
faustus@ucbcad.berkeley.edu (Wayne A. Christopher) (01/13/87)
In article <1639@enea.UUCP>, sommar@enea.UUCP (Erland Sommarskog) writes: > To get I/O-routines (or whatever scanf() is) with variable parameter lists, > there seems to be four ways: > 1) Make them standard routines recognized by the compiler. The best alter- > native. Specially in a small langauge like C. > 2) Introduce a syntax that allows this. Possible, but not very attrcative. > 3) Skip checking of parameter count. To be straight: Ridiculous. > 4) Forget the whole thing. You're assuming that there is no use for variable argument lists besides printf() and scanf(). This isn't true -- I use them all the time... (Well, now and then....) Your solution (1) doesn't address this problem, solution (2) is already in C (it's called "varargs"), (3) is what C used to do, and (4) is unacceptable. Wayne
chris@mimsy.UUCP (Chris Torek) (01/14/87)
In article <1639@enea.UUCP> sommar@enea.UUCP (Erland Sommarskog) writes: >To get I/O-routines (or whatever scanf() is) with variable parameter lists, >there seems to be four ways: >1) Make them standard routines recognized by the compiler. The best alter- > native. Specially in a small langauge like C. This is bad because it cannot be extended, not without hacking the compiler. >2) Introduce a syntax that allows this. Possible, but not very attrcative. This is `not very attractive' because it clutters up the syntax? >3) Skip checking of parameter count. To be straight: Ridiculous. This is bad because it does not do something that could be done, and that has proven worthwhile in similar cases. >4) Forget the whole thing. This is bad because it makes the language harder to use. I claim that the proper solution is 1 and/or 2: What is needed is a way of telling the compiler, `this routine takes arguments described by . . .' that is general enough to cover printf, scanf, execl, and so forth, yet simple enough so that new ones can be introduced as necessary, and so that the syntax is not unduly cluttered. The real problem is in conveying the `described by' part. System V lint has /*PRINTFLIKE*/ and /*SCANFLIKE*/ pragmas in its lint library, which takes care of printf and scanf and variants, but not execl. Would adding /*REPEATING*/ suffice? I cannot say. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
adam@gec-mi-at.co.uk (Adam Quantrill) (01/15/87)
In article <745@drivax.UUCP> holloway@drivax.UUCP (Bruce Holloway) writes: > >Pascal puts in a lot of code for array overruns, etc., that are unnecessary for >a well-designed program. You could turn all this off on the Pascal I learned >on, which made it tolerable. But I don't want anything in the program I didn't >put there -- if I'd wanted subscript checking, I would have added it. Turning off compiler checking after the program is debugged is like throwing away your lifeboats after the maiden voyage. -Adam.
karl@haddock.UUCP (01/16/87)
[I've added comp.lang.c to the discussion. --kwzh] In article <5064@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: [Re the problem of type-checking on varargs functions] >What is needed is a way of telling the compiler, `this routine takes >arguments described by ...' that is general enough to cover printf, scanf, >execl, and so forth, yet simple enough so that new ones can be introduced as >necessary, and so that the syntax is not unduly cluttered. The real problem >is in conveying the `described by' part. System V lint has /*PRINTFLIKE*/ >and /*SCANFLIKE*/ pragmas in its lint library, which takes care of printf and >scanf and variants, but not execl. Would adding /*REPEATING*/ suffice? I >cannot say. Functions like execl(), which are variadic but not polymorphic, are the simple case; adding /*REPEATING*/ and /*SENTINEL (char *)0*/ would be sufficient to document these.* Some functions switch on one arg to determine how to process the others. (I think these should be avoided in favor of separate functions when possible.) These could be documented to lint as follows: /* SWITCHON 2 */ int ioctl(int, TIOCNOTTY); int ioctl(int, TIOCGPGRP, int *); int ioctl(int, TIOCSPGRP, const int *); int ioctl(int, TIOCSTI, const char *); However, this notation doesn't quite cover SysV open(). /*PRINTFLIKE*/, etc are a kludge; they require the syntax rules to be built into the typechecker. (The printf-like routine in adb, e.g., is excluded.) To handle this in full generality would require something like an correctness- proving language. Fortunately, few variadic functions are of this type (and the standard ones, as mentioned, are hard-coded). Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint *Along with /*SENTINEL*/, there should be another notation for functions whose arg count is explicitly passed as one of the arguments. Neither of these would be necessary if C supported nargs().
barmar@mit-eddie.UUCP (01/17/87)
In article <1639@enea.UUCP> sommar@enea.UUCP (Erland Sommarskog) writes: >To get I/O-routines (or whatever scanf() is) with variable parameter lists, >there seems to be four ways: >1) Make them standard routines recognized by the compiler. The best alter- > native. Specially in a small langauge like C. >2) Introduce a syntax that allows this. Possible, but not very attrcative. >3) Skip checking of parameter count. To be straight: Ridiculous. >4) Forget the whole thing. #2 this is the approach taken in ANSI C. I sure hope it is possible, and I guess C programmers should get used to the idea even if they don't find it attractive. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
aeusemrs@csun.UUCP (Mike Stump) (01/19/87)
In article <492@gec-mi-at.co.uk> adam@gec-mi-at.co.uk (Adam Quantrill) writes: >Turning off compiler [array bounds] checking after the program is >debugged is like throwing away your lifeboats after the maiden voyage. Let me be the first to responed to your letter. I am not sure about you, but I would rather have a program that runs faster, and in one chance in a couple thousand `goes down in flames' than a program that runs slower and in one chance in a couple thousand says something to the effect: `FATAL: array overflow'... Also, I think your analogy is a bit off. `My boats DONT sink', 8-> therefor, why WASTE money on lifeboats? :-) -- Mike Stump, Cal State Univ, Northridge Comp Sci Department uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs
franka@mmintl.UUCP (Frank Adams) (01/20/87)
In article <594@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP writes: >NO. The compiler does not treat scanf(), printf(), etc, any >differently from any routine which is defined in another file. They >are "standard" only in that (almost) all environments which support C >also support these routines. Pascal, on the other hand, does things >for write(), writeln(), etc, differently from the way it handles calls >to user routines. Many Fortran implementations do *not* treat variable-argument subroutines (such as MAX) any differently from other calls. (At least one, for TOPS-10, deals with a two-argument MAX inline, but generates an ordinary function call for more than two arguments.) Pascal does make it impossible to even define such functions for use in the language -- this is a grave deficiency, but not really the fault of the type-checking. Fortran does not permit such routines to be written in the language, meaning that some portion of your system must be in some other language (usually assembler) if you have need of such tricks. But C doesn't really provide any way to write such routines in the language either -- not portably. varargs does provide a way to do this, but (1) many current C implementations do not support varargs, and (2) varargs is a *kludge*. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
jtr485@umich.UUCP (Johnathan Tainter) (01/20/87)
In article <492@gec-mi-at.co.uk>, adam@miduet.UUCP writes: > In article <745@drivax.UUCP> holloway@drivax.UUCP (Bruce Holloway) writes: >>Pascal puts in a lot of code for array overruns,etc., that are unnecessary for >>a well-designed program. You could turn all this off on the Pascal I learned >>on, which made it tolerable. But I don't want anything in the program I didn't >>put there -- if I'd wanted subscript checking, I would have added it. > Turning off compiler checking after the program is debugged is like > throwing away your lifeboats after the maiden voyage. > -Adam. Bruce never said anything about debugging the program. He said well designed. The verb 'debug' does not really have a past tense as it is never possible to be sure you are done. Of course, if Bruce really doesn't want anything in the code he didn't put there then he really ought to be programming in assembler. The pascal(*) I program in on a regular basis allows you to turn this off for selective portions of the code. I use this quite often to reduce the space and improve performance of the code. However, I have to thoroughly convince myself that this bit of optimization is safe before doing it. --j.a.tainter *UCSD Pascal is one of the best pascal supersets around, the only serious flaw is 16 bit pointers
robison@uiucdcsb.cs.uiuc.edu (01/20/87)
> ... I am not sure about you, but I would rather have a program that runs > faster, and in one chance in a couple thousand `goes down in flames' than a > program that runs slower and in one chance in a couple thousand > says something to the effect: `FATAL: array overflow'... > Also, I think your analogy is a bit off. `My boats DONT sink', 8-> > therefor, why WASTE money on lifeboats? :-) > -- Suppose your CAD program for nuclear-powered boats has the error-checking turned off. So instead of `FATAL: array overflow' some data is corrupted (without any indication) and you go ahead and build the boat, which promptly sinks. One chance in a couple thousand is not good enough. I think most of the checks causing significant slowing could be verified by static analysis at compile time and the run-time check not inserted. E.g. some simple range analysis could show many subscript-checks are provably unnecessary. Presumably its only a few checks in the inner-most loops that cause the program to run signifcantly slower. There's some papers on range analysis in: Program Flow Analysis: Theory and Applications Steven S. Muchnick & Neil D. Jones Prentice-Hall, Inc. Englewood Cliffs, New Jersey 1981 Arch D. Robison robison@uiucdcs University of Illinois at Urbana-Champaign