Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!mhuxf!mhuxi!mhuhk!mhuxt!houxm!ihnp4!bentley!kwh From: kwh@bentley.UUCP (KW Heuer) Newsgroups: net.lang.c Subject: Re: What should be added to C Message-ID: <852@bentley.UUCP> Date: Sun, 25-May-86 19:36:13 EDT Article-I.D.: bentley.852 Posted: Sun May 25 19:36:13 1986 Date-Received: Wed, 28-May-86 01:48:41 EDT References: <5498@alice.uUCp> <1462@mmintl.UUCP> Organization: AT&T Bell Laboratories, Liberty Corner Lines: 121 In article <1462@mmintl.UUCP> mmintl!franka (Frank Adams) proposes: >> o Min and max operators. These would get used all over the place. These >> should be usable to the left of the assignment operator, as most but not all >> C operators are. In article <5498@alice.uUCp> alice!ark responds: >What would it mean to use these on the left of an assignment, >and why would you want to use it? I think he means that in addition to MIN and MAX there should be MIN= and MAX= operators. I think this is a good reason for making them operators rather than functions. "x MIN= y" is clearer than "if (x > y) x = y", since the latter can easily be misread as "x MAX= y", besides being subject to side effects. >> o An andif clause for if statements. > >What does it do and how would you use it? More specifically, how does it differ from "&&"? >> o The ability to define multi-line pre-processor macros, using #begdef and >> #enddef statements. #if and other conditionals in the body of the >> definition would be evaluated when the macro was not interpreted, not when >> it is encountered. The m4 preprocessor already has this functionality, and more. Of course, if using C without UNIX(R), you may not have m4... >> o A typeof operator, similar to sizeof. > >What would its value be? Why would you want to use it? Presumably "typeof(variable)" would be syntactically a dataype, so it's not really appropriate to call this an "operator". There's one obvious use, "p = (typeof(*p) *)malloc(sizeof(*p))". I guess you could also use it in "#define swap(x,y) {typeof(x) temp; temp=x; x=y; y=temp;}". I don't know that either of these is very useful, though. >> o := as a synonym for =. Compilers could have an option to permit := only. To help catch "=" vs. "==" errors? Or just to make PASCAL users happy? (And then we could make "<>" a synonym for "!=", and ...) >> o Permit a continue statement in switch [to denote fall-through]. I'll address this elsewhere. >> o Any sort of multi-level break statement. No! If you have code that seems to require a multi-level break, you should think some more about the problem you're trying to solve. If it's really necessary, use a goto. (I very seldom use even a one-level break, except as the unique exit point in a "for (;;)" loop when it's too far from either end to conveniently convert it into a "while" or "do".) >The trouble with adding new features to C is that there is a very >strong incentive not to use them. After all, any program that >uses some new feature is only going to run on machines that support >that feature. I don't think I'm going to be using only one compiler >for the rest of my life and would like to avoid changing my code >every time the environment hiccups. Does this mean you don't use enum, void, or struct assignment? The "best" solution is to add the features to the official definition of the language, but avoid using them in your code until "all" machines support those features. >>exchange operator. This one is quite frequently useful, and the >>alternatives are ugly. Taking into consideration how bad the alternatives are, it *might* be a good idea to make this a builtin operator; perhaps ":=:". Either Andy's suggestion of a concurrent assignment operator (could this possibly be made a variant of struct assignment?) or my ",," operator would be more powerful, if you don't have to worry about side effects. (How often do you need "a[i++] SWAP a[j++]" anyway?) >>I do not support the following: >> >>o ^^ for logical exclusive or. I agree with you here. If both sides are true booleans (value zero or one), either "^" or "!=" will do. If not, then the user can just use the standard "cast to boolean", namely "... != 0". There's no loss of efficiency since that's exactly how the compiler evaluates an integer in a boolean context, and it probably makes the code easier to read, too. >>o Doing anything about the array/pointer relationship. What we have now is >>a mess, but any attempt to fix it will produce a worse mess, either in the >>language or with existing code. Well, the change from "=OP" to "OP=" also broke existing code, but was done quite nicely by phasing it in slowly. I think it's possible to implement arrays cleanly and introduce the changes gradually, but it's questionable whether this should be done to C. One could instead create a new language "D" (or "P" if you prefer that sequence), which fixes several problems in C without trying to be syntactically a superset of it. A C-to-D translation program would be a big plus. >>o A separate boolean data type (sigh). This is a good thing to have in a >>language, but not a good thing to add to C as it exists. I'm not sure why not. Assuming all the implicit int/bool conversions stay, I think the only problems are (a) it isn't really necessary, and (b) it adds a new reserved word (breaking any programs that use "typedef int bool"!). >>o There should be an option to flag statements of the form if (v = e) ... >>(Actually, I wouldn't be averse to a coding standard which forbade such >>things, in favor of if (v = e, v) ...) Urgh. Are you talking about removing the assignment-has-a-value feature completely, or a special case for "if (v = e)"? (I always write this as "if ((v = e) != 0)" to make it clear that I didn't mean "if (v == e)".) Actually, the main argument in favor of valued assignment is to allow such things as "while ((c = getchar()) != EOF)". This really doesn't look so bad with the unvalued assignment "while (c = getchar(), c != EOF), so it may not be such a bad idea. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Wait until you see *my* complete list of ideas!