franka@mmintl.UUCP (Frank Adams) (05/17/86)
As has been noted, one should use restraint in adding new features to a
language. What follows is a list of the features I would support adding to
the *next* version of C (after the current standard is complete).
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.
o An andif clause for if statements.
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.
o A typeof operator, similar to sizeof.
o := as a synonym for =. Compilers could have an option to permit := only.
o Permit a continue statement in switch, meaning that the next label should
be fallen through to. Compilers and/or lint could produce when a program
falls through without a continue statement.
o Any sort of multi-level break statement. There is no syntacticly clean
way of adding this to C.
o Elimination of the eight-character truncation of internal variable names
done by some compilers. (This may be in the current spec; I haven't read
that document.) The entire length of a variable name should be significant.
I do not support the following:
o ^^ for logical exclusive or. Unlike the other "short-circuit" forms (&&
and ||), this doesn't save any execution -- both operands must be evaluated.
A good optimizing compiler should be able to tell that both operands to an ^
must be 0 or 1 if they are the result of comparisons or other logical
operators; if a typedef is used for booleans, boolean variables can likewise
be recognized.
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.
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 might support
having bool predefined as enum {false, true}; but the implications for
existing code are not trivial.
There are several things which are not part of the language definition, but
which would be useful in compilers. These consist mostly of flagging
certain statements with (at least) warning messages.
o Statements with obviously unpredictable side effects (such as
a[i] = b[i++];) should be flagged.
o An integer constant passed to a function, which is taken to be long
instead of int because of its size, should be flagged. (This need not be
done if the parameter types for the function have been declared.)
o A comparison which always yields the same result because of type
considerations (e.g., comparing a signed character to 128) should be flagged.
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) ...)
I am aware that some of these things are flagged by some compilers. Please
don't bother either me or the rest of the net by telling us about compilers
which do so.
Frank Adams ihnp4!philabs!pwa-b!mmintl!franka
Multimate International 52 Oakland Ave North E. Hartford, CT 06108franka@mmintl.UUCP (Frank Adams) (05/17/86)
Something which got forgotten in my original article: I would favor an exchange operator. This one is quite frequently useful, and the alternatives are ugly. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
dgary@ecsvax.UUCP (D Gary Grady) (05/20/86)
Right now Fortran has four things over C:
o A richer set of floating point operators, including exponentiation and
the so-called "in-line" functions (many of which ARE in C).
o A way of passing different-sized multidimensional arrays to the same
subroutine. (For instance, right now it is not possible to write a
function in C that will invert a matrix of arbitrary size without use
of some "trick," like making the incoming matrix one-dimensional and
hard-coding the subscript computation or using arrays of pointers to
pointers.)
o A very well-standardized set of subroutines and functions for
scientific and engineering use.
o COMPLEX type.
C++ (with which I am unfamiliar) solves some of these problems, I
believe. For instance, it is possible to do operator overloading, so
the COMPLEX type can be implemented in a fashion similar to Ada's.
--
D Gary Grady
Duke U Comp Center, Durham, NC 27706
(919) 684-3695
USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgaryark@alice.UucP (Andrew Koenig) (05/20/86)
Frank Adams says: > As has been noted, one should use restraint in adding new features to a > language. What follows is a list of the features I would support adding to > the *next* version of C (after the current standard is complete). OK, let's see his examples of "restraint:" > 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. What would it mean to use these on the left of an assignment, and why would you want to use it? > o An andif clause for if statements. What does it do and how would you use it? > 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. Why would you want to use it? > o A typeof operator, similar to sizeof. What would its value be? Why would you want to use it? > o := as a synonym for =. Compilers could have an option to permit := only. Why bother? > o Permit a continue statement in switch, meaning that the next label should > be fallen through to. Compilers and/or lint could produce when a program > falls through without a continue statement. A continue statement is already legal in a switch, as long as that switch is enclosed in a for or while. It means go on to the next iteration of the enclosing loop. Are you proposing to change this? > o Any sort of multi-level break statement. There is no syntacticly clean > way of adding this to C. C already has a multi-level break statement. It's spelled "goto." Putting a goto in a costume doesn't disguise it. > o Elimination of the eight-character truncation of internal variable names > done by some compilers. (This may be in the current spec; I haven't read > that document.) The entire length of a variable name should be significant. Most compilers do this already. 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.
dlnash@ut-ngp.UUCP (Donald L. Nash) (05/20/86)
In article <1462@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: > > o := as a synonym for =. Compilers could have an option to permit := only. > Why? "Since assignment is about twice as frequent as equality testing in typical C programs, it's appropriate that the operator be half as long." K&R, p. 17. Allowing := as a synonym is OK, if you prefer that operator, but why would you want to make it manditory? > > o Any sort of multi-level break statement. There is no syntacticly clean > way of adding this to C. > How about using goto? Some people may think that goto sucks wind, but it is a perfectly legitimate statement which can get you out of trouble, if properly used. > I do not support the following: > > o ^^ for logical exclusive or. Unlike the other "short-circuit" forms (&& > and ||), this doesn't save any execution -- both operands must be evaluated. So what if they both have to be evaluated? If you need to use some kludge to get ^^ (like !a != !b), you will still wind up evaluating both operands. That's just the way XOR works. Just because it requires more work is no reason to exclude it from the language. > > Frank Adams ihnp4!philabs!pwa-b!mmintl!franka > Multimate International 52 Oakland Ave North E. Hartford, CT 06108 I don't want to come off sounding like a fluff picker, so just for the benefit of those of you who care, I did agree with the rest of the article. If net traffic weren't such a big issue, I'd have included the rest of the article as well, with more agreeable comments added. Don Nash UUCP: ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!dlnash APRA: dlnash@ngp.CC.UTEXAS.EDU BITNET: cceu001@utadnx "If you can't say something nice, then don't" -- Thumper the rabbit
6063366@pucc.BITNET (Carl Micarelli) (05/21/86)
In article <1462@mmintl.UUCP>, Frank Adams (franka@mmintl.UUCP) suggests adding the following to C: >o Any sort of multi-level break statement. There is no syntacticly clean >way of adding this to C. Good idea, but I don't think there's any syntactically clean way of implementing a multi-level break statement in C -- at least no way that's preferable to a goto. >There are several things which are not part of the language definition, but >which would be useful in compilers. These consist mostly of flagging >certain statements with (at least) warning messages. Requiring compilers to flag constructions that look like bugs is a good idea, but only if you establish a standard way of forcing the compiler to (selectively) shut up. >(Actually, I wouldn't be averse to a coding standard which forbade such >things [as if (v = e) ... ], in favor of if (v = e, v) ...) No! = is an operator, v=e has a value, and its value should be usable anywhere. Making up special rules -- even for the noble purpose of protecting programmers from carelessness or typos -- just complicates things. Carl Micarelli - BITNET: 6063366@pucc UUCP: ...allegra!psuvax1!pucc.bitnet!6063366
roy@phri.UUCP (05/21/86)
In article <1463@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > Something which got forgotten in my original article: I would favor an > exchange operator. This one is quite frequently useful, and the > alternatives are ugly. Why don't we just invent a new language? We could call it PL/2. -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
aglew@ccvaxa.UUCP (05/22/86)
>/* Written 8:04 pm May 16, 1986 by franka@mmintl.UUCP in ccvaxa:net.lang.c */ >/* ---------- "Re: What should be added to C" ---------- */ >Something which got forgotten in my original article: I would favor an >exchange operator. This one is quite frequently useful, and the >alternatives are ugly. > >Frank Adams ihnp4!philabs!pwa-b!mmintl!franka >Multimate International 52 Oakland Ave North E. Hartford, CT 06108 >/* End of text from ccvaxa:net.lang.c */ Why not go all the way and implement Dijkstra's concurrent assignment? i,j := j,i for a swap. Course, couldn't use commas, but you get the idea. Compilers can generate good code for this, and it makes programs with complicated pointer manipulations much clearer; I used to teach it, and the associated code generation algorithm, to U1s in classes I TAed, and it greatly reduced the noise level of assignments in the wrong order. #define swap(a,b) a,b := b,a does the exchange without having to type the name twice. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms
ljz@well.UUCP (Lloyd Zusman) (05/22/86)
In article <2355@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: ... >> Something which got forgotten in my original article: I would favor an >> exchange operator. This one is quite frequently useful, and the >> alternatives are ugly. > > Why don't we just invent a new language? We could call it PL/2. ... or ADA++
franka@mmintl.UUCP (Frank Adams) (05/23/86)
In article <5498@alice.uUCp> ark@alice.UUCP writes: >Frank Adams says: > >> As has been noted, one should use restraint in adding new features to a >> language. What follows is a list of the features I would support adding to >> the *next* version of C (after the current standard is complete). > >OK, let's see his examples of "restraint:" > >> 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. > >What would it mean to use these on the left of an assignment, >and why would you want to use it? It would mean what it usually means. If "\/" is the minimum operator, then "a \/= b" would mean "a = a \/ b". I find it hard to believe that anyone with any programming experience would need to ask why you would want to use it. >> o An andif clause for if statements. > >What does it do and how would you use it? You would write: if (A) { X } andif (B) { Y } else { Z } This is equivalent to: if (!(A)) goto _Z; X if (B) { Y } else { _Z: Z } >> 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. > >Why would you want to use it? To write more sophisticated macros. For example, one could write a copy macro which would invoke strcpy in most cases, but a word copy routine to copy an array of structures whose size is a multiple of a word. Such a macro would be machine dependant -- this is exactly the reason for making it a macro, instead of hard coding the calls. >> o A typeof operator, similar to sizeof. > >What would its value be? Why would you want to use it? "typeof(x)" would be a type, which is the type that x was declared as. This is for use primarily in macros. >> o := as a synonym for =. Compilers could have an option to permit := only. > >Why bother? Confusing "=" and "==" in if statements is a common mistake. If "=" is not a legal operator, this error becomes very rare. >> o Permit a continue statement in switch, meaning that the next label should >> be fallen through to. Compilers and/or lint could produce when a program >> falls through without a continue statement. > >A continue statement is already legal in a switch, as long as that >switch is enclosed in a for or while. It means go on to the next >iteration of the enclosing loop. Are you proposing to change this? Yes. >> o Any sort of multi-level break statement. There is no syntacticly clean >> way of adding this to C. > >C already has a multi-level break statement. It's spelled "goto." >Putting a goto in a costume doesn't disguise it. You weren't reading very carefully. This was on my list of things which should *not* be added. >> o Elimination of the eight-character truncation of internal variable names >> done by some compilers. (This may be in the current spec; I haven't read >> that document.) The entire length of a variable name should be significant. > >Most compilers do this already. So let's make it part of the standard, and those of us who like to write portable code can start using it. >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. This is the whole point of having a standard. It gives you some assurance that compilers which use the features will be available. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
franka@mmintl.UUCP (Frank Adams) (05/23/86)
In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <5498@alice.uUCp> ark@alice.UUCP writes: >>Frank Adams says: >>> o Any sort of multi-level break statement. There is no syntacticly clean >>> way of adding this to C. >> >>C already has a multi-level break statement. It's spelled "goto." >>Putting a goto in a costume doesn't disguise it. > >You weren't reading very carefully. This was on my list of things which >should *not* be added. My apologies. This was *intended* to be on the list of things which should not be added. However, it inadvertently got put on the wrong list. As I said, there is no syntactically clean way of adding this feature. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
greg@utcsri.UUCP (Gregory Smith) (05/24/86)
In article <5498@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >> 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. > >What would it mean to use these on the left of an assignment, >and why would you want to use it? Just like i += x;: i /\= j; means if( j>i ) i=j; ( very common ) >> 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. > >Why would you want to use it? When your macro won't fit on a line, and/or you want to use #if's etc as part of the macro, obviously. To fully support this, you'd want to add #ifsame <arg1> <arg2>, and things like that, like MACRO-11's assembler macros. How about #rpt n, and #irp SYM,list ? I don't think the current cpp is doing enough to justify it being a seperate pass. ( although I would rather see its role given to the compiler, via constant types, etc. `if(con_exp){..}' could be ignored if con_exp == 0, etc.) > >> o A typeof operator, similar to sizeof. > >What would its value be? Why would you want to use it? > x = (typeof x ) malloc ( n * sizeof( *x )); >> o := as a synonym for =. Compilers could have an option to permit := only. > >Why bother? ever write if( x=2 ){ ... ???? I like this idea a lot. > > >> o Any sort of multi-level break statement. There is no syntacticly clean >> way of adding this to C. break; break 2; break 3; break [con_exp]; > >C already has a multi-level break statement. It's spelled "goto." >Putting a goto in a costume doesn't disguise it. > When a human reading a program sees 'break', it is immediately known that the current loop is being abandoned. In order to determine the effect of a goto, you have to find its destination. If you don't believe there is a big difference, try maintaining someone else's BAS*C code sometime. >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. You're absolutely right. Let's all use K&R C only for the rest of time. -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
greg@utcsri.UUCP (Gregory Smith) (05/25/86)
In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > >>> o An andif clause for if statements. > >You would write: > > if (A) { > X > } andif (B) { > Y > } else { > Z > } > >This is equivalent to: > > if (!(A)) goto _Z; > X > if (B) { > Y > } else { >_Z: > Z > } > Interesting - like a switch, but with dynamic conditions. How about actually writing it like a switch: switch(){ /* or just 'switch{' */ when A: X; break; when B: Y; break; default: Z; } A and B, are arbitrary expressions which are evaluated in sequence. Sorry about stealing the extra keyword. Actually, 'case' would work just as well; and it wouldn't really be confusing, since one type of switch *must* have a constant exp and the other type would have to have non-constant expressions in reasonable usage. This would be easy to compile, and much more readable than an if..else.. etc. >>> o Any sort of multi-level break statement. There is no syntacticly clean >>> way of adding this to C. I don't agree. what about statement ::= break ; | break constant_exp ; e.g. break 2; would break the current loop *and* the enclosing one. Of course, you can obfuscate this with #define BRKS 3; ... break BRKS; /* ;-) */ -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
ark@alice.UucP (Andrew Koenig) (05/25/86)
> Why not go all the way and implement Dijkstra's concurrent assignment? > i,j := j,i > for a swap. Course, couldn't use commas, but you get the idea. > Compilers can generate good code for this, and it makes programs with > complicated pointer manipulations much clearer; I used to teach it, and the > associated code generation algorithm, to U1s in classes I TAed, and it > greatly reduced the noise level of assignments in the wrong order. Two comments: 1. This is really not the same as a swap. I would like to be able to say something like swap (a[i++], a[j++]); and have it do the right thing, effectively a[i],a[j] = a[j],a[i]; i++, j++; This is definitely not equivalent to a[i++], a[j++] = a[j++], a[i++]; 2. Can you give me a simple code generation algorithm for multiple assignments that gets things like i, a[i] = j, a[j]; correct and never uses extra temporaries? I have this nagging feeling that even without subscripted variables, the problem is NP-complete.
kwh@bentley.UUCP (KW Heuer) (05/26/86)
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!
augart@h-sc2.UUCP (augart) (05/27/86)
>>> 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. >> >>Why would you want to use it? > >When your macro won't fit on a line, and/or you want to use #if's etc >as part of the macro, obviously. If your macro won't fit on a line, you can already handle this problem by finishing off each line except the last with a backslash. The other addition would be a win, though. Steven Augart swa@xx.lcs.mit.edu
bet@ecsvax.UUCP (Bennett E. Todd III) (05/27/86)
In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <5498@alice.uUCp> ark@alice.UUCP writes: >>Frank Adams says: >>> o An andif clause for if statements. >> >>What does it do and how would you use it? > >You would write: > > if (A) { > X > } andif (B) { > Y > } else { > Z > } > >This is equivalent to: > > if (!(A)) goto _Z; > X > if (B) { > Y > } else { >_Z: > Z > } Why not use if (A) { X if (B) { Y } } else { Z } -Bennett -- Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695 UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
jimc@iscuva.UUCP (Jim Cathey) (05/27/86)
I got messed up in figuring out who wrote what here, and had to dump the names, but that is not the point. >> >> o := as a synonym for =. Compilers could have an option to permit := only. >> > >Why? "Since assignment is about twice as frequent as equality testing >in typical C programs, it's appropriate that the operator be half as long." >K&R, p. 17. Allowing := as a synonym is OK, if you prefer that operator, >but why would you want to make it manditory? YES, I HATE `:='. While I admit it is easy to read, the fact that on all the keyboards I've used except the IBM keypunch, the two symbols are in different cases and very awkward to type...and yes, I do know about smart editors! >> I do not support the following: >> >> o ^^ for logical exclusive or. Unlike the other "short-circuit" forms (&& >> and ||), this doesn't save any execution -- both operands must be evaluated. YES! >So what if they both have to be evaluated? If you need to use some >kludge to get ^^ (like !a != !b), you will still wind up evaluating both >operands. That's just the way XOR works. Just because it requires more >work is no reason to exclude it from the language. I think this misses the point. The short-circuit versions of AND and OR are just that - SHORT CIRCUIT versions! These are intended to be used in place of the regular AND and OR when appropriate, to avoid much extra if () testing. I think K&R makes this clear. I do admit that you can almost always use the short circuit versions in conditionals even when not required, for efficiency's sake. Just gotta watch the side-effects and parentheses! if (one_expr | the_other_expr) then_barfo; if (one_expr & the_other_expr) then_barfo; will often work just as well as: if (one_expr || the_other_expr) then_barfo; if (one_expr && the_other_expr) then_barfo; provided that the two expressions evaluate to whatever a boolean int is locally (1 or -1). {BTW I usually use set_me_true = (1 == 1)} For XOR, where there can be no concept of a short circuit, one should be using the regular ^ operator instead. Something like: if (one_expr ^ the_other_expr) then_barfo; given the above restrictions. A ^^ operator is syntactically null given the theme expressed by AND and OR. Of course, if the expressions being tested are not 'boolean', then the single-character operators can fail where the double-character operators will succeed. If you are using the double-character operators as boolean-normalizing flavors of the single-character operators, then I can see the point in wanting a ^^. This, to me, is not what was intended when && and || were created. -- +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! Spokane, WA ! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!jimc ! II CCCCCC ! (509)927-5757 +----------------+ "With excitement like this, who is needing enemas?"
kab@reed.UUCP (Kent Black) (05/28/86)
In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >>> o An andif clause for if statements. > >You would write: > > if (A) { > X > } andif (B) { > Y > } else { > Z > } > >This is equivalent to: > > if (!(A)) goto _Z; > X > if (B) { > Y > } else { >_Z: > Z > } Which is equivalent to: if (A) { X; if (B) { Y; } } else { Z; } n'est pas? I find the last easier to read (if not A, skip B altogether, rather than putting B at the same `level' as its predicate). Can you provide an example that is significantly `clearer' (whatever meaningful term you prefer ;-) with an 'andif' than with nesting in the block? (N.B., this is not just another `but we don't really NEED that' argument; I found the 'andif' obfuscatory. Consider: if (A) X andif (B) Y andif (C) /* if A && !B or if A && B ? */ etc ) ----------------------------------------- >>> o Elimination of the eight-character truncation of internal variable names >>> done by some compilers. ... >So let's make it part of the standard, and those of us who like to write >portable code can start using it. Well, you don't *really* make code portable by defining it to be so ;-) (no, responses to my foolishness are not necessary) >Frank Adams ihnp4!philabs!pwa-b!mmintl!franka >Multimate International 52 Oakland Ave North E. Hartford, CT 06108 ----------------------------------------- Kent Black ...tektronix!reed!kab
bright@dataioDataio.UUCP (Walter Bright) (05/28/86)
In article <2823@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >In article <5498@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >>> 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. I thought that multi-line macros could be done by terminating the line with a \. Such as: #define abc(d) a \ = \ d; By the way, Datalight C allows things such as: #define abc(d) a = \ #if XYZ == 47 \ 54; \ #else \ 56; \ #endif The preprocessor commands are considered as part of the macro text, and are parsed as preprocessor commands after the macro has been expanded. >>> o A typeof operator, similar to sizeof. > x = (typeof x ) malloc ( n * sizeof( *x )); The macro I always wanted to write is: #define swap(a,b) { typeof(a) temp; \ temp = (a); \ (a) = (b); \ (b) = temp; \ } >>> o := as a synonym for =. Compilers could have an option to permit := only. Clutter. It's easier to cause the compiler to generate a warning for constructs such as: if (a=b) { ... } >>> o Any sort of multi-level break statement. There is no syntacticly clean >>> way of adding this to C. >>C already has a multi-level break statement. It's spelled "goto." >>Putting a goto in a costume doesn't disguise it. >When a human reading a program sees 'break', it is immediately known >that the current loop is being abandoned. In order to determine the >effect of a goto, you have to find its destination. If you don't >believe there is a big difference, try maintaining someone else's >BAS*C code sometime. There's no problem finding where a goto goes to if you have only one or two in a function. Gotos only become a problem when you have a snarl of them. What I find confusing is four page functions, with 47 levels of ifs and {}s, and trying to figure out where control flow goes when a break happens. You have to count }s, or run a listing and connect the {}s with a pen. I've had people do greps for gotos on my code, show me an out-of- context list of the 14 they found in 10,000 lines of C, and tell me that my code was bad. Using only structured programming constructs only guarantees that the flow graph for your program will be reducible, it doesn't guarantee that your program is structured. The only purpose to having a reducible flow graph is if your optimizer can't handle irreducible ones.
aglew@ccvaxa.UUCP (05/28/86)
~> Things that should/could be added to C, or C++, or...
typeof
typeof would be a compile time operator that would
have a (possibly compressed and tokenized) form of
the type used in declaring its argument (a variable)
inserted in its place.
If the C preprocessor ever gets sophisticated enough
to be a true macro processor, typeof should return a
string that macro operations can parse and disassemble
as they will. In particular, typeof(typedef-name)
should return the type used in declaring the type-name,
and so on.
lambda
Wherever you may have a variable, it should be possible
to substitute a literal constant of the appropriate type.
C fails this test for arrays, which hasn't been so serious
for the applications I've seen (I don't like having to declare
COMPLEX constants as initialized variables, but C has so many
other weaknesses for constants that I don't care - I'll wait
for C++ constructors) -- more importantly, C also fails this
test for function-pointers.
When I pass a function pointer to, say, an integration routine,
I would like to not have to go to the bottom of the file
somewhere and write the function. f it's a short, anonymous
function that I'm not going to use anywhere else, I want to
declare it in place.
I've used preprocessors that let you do this:
integrate(from,to,
float lambda(x) float x; {return x*x;}
)
and move the declaration to the end and create a special name
for it.esg@mtx5a.UUCP (ed gokhman) (05/28/86)
C++ makes a few interesting enhancements to its C subset. While playing with C++, I found at least two new features to be very usefull: 1. inline specifier. This is a better alternative to macros in that you may have return values for multi-statement macros. Plus, of cause, having a frequently used feature defined in language proper is nice. 2. Reference variables, e.g. int& i, used to provide call by reference and implemented as a pointer to a variable that is dereferenced every time it is used. I would rather see C++ and Concurrent C making their way into the ANSI standard, but, if it is unfeasible, at least their usefull additions to the "old C" should see the world. Ed Gokhman
faustus@cad.BERKELEY.EDU (Wayne A. Christopher) (05/29/86)
In article <1497@mmintl.UUCP>, franka@mmintl.UUCP writes: > You would write: > > if (A) { > X > } andif (B) { > Y > } else { > Z > } > > This is equivalent to: > > if (!(A)) goto _Z; > X > if (B) { > Y > } else { > _Z: > Z > } It is also equivalent to: if (A) { X if (B) { Y } } if (!A || !B) Z } I think this looks cleaner, but in any case it isn't an often-encountered situation and the semantics aren't obvious. > To write more sophisticated macros. For example, one could write a copy > macro which would invoke strcpy in most cases, but a word copy routine to > copy an array of structures whose size is a multiple of a word. Such a > macro would be machine dependant -- this is exactly the reason for making it > a macro, instead of hard coding the calls. You can write arbitrarily large macros by putting backslashes at the end of lines. This is ugly but it works. > Confusing "=" and "==" in if statements is a common mistake. If "=" is not > a legal operator, this error becomes very rare. It's also an extra character to type. If you are prone to this sort of error, just run your code through grep if | grep = | grep -v == ... > >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. > > This is the whole point of having a standard. It gives you some assurance > that compilers which use the features will be available. If the standard has all the things you enumerate, not many people will follow it and it will be worse than no standard at all. Wayne
franka@mmintl.UUCP (Frank Adams) (05/29/86)
In article <5521@alice.uUCp> ark@alice.UUCP writes: > 2. Can you give me a simple code generation algorithm > for multiple assignments that gets things like > > i, a[i] = j, a[j]; > > correct and never uses extra temporaries? I have this > nagging feeling that even without subscripted variables, > the problem is NP-complete. I wouldn't be surprised. But this is not intolerable; most cases are quite small, and even moderately large ones are very rare. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
aglew@ccvaxa.UUCP (05/30/86)
~> Multi-level breaks
I have never liked breaks with a numeric argument; I cut my teeth on
WATFOR/WATFIV, and I can assure you that they do *not* make things
much clearer.
Why not use the Ada style of putting a label before the loop body - it's
like giving a name to the loop:
complicated_loop: for(;;) {
{{{{{
break complicated_loop;
}}}}}
}
No, it's not really much different from a goto.
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vmsg-rh@cca.UUCP (Richard Harter) (05/30/86)
In article <> greg@utcsri.UUCP (Gregory Smith) writes: >In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > >>>> o Any sort of multi-level break statement. There is no syntacticly clean >>>> way of adding this to C. > >I don't agree. what about >statement ::= break ; > | break constant_exp ; > >e.g. break 2; >would break the current loop *and* the enclosing one. > This is a chestnut. 'break n' type constructs have been tried and found wanting. The problem is that it can make code maintenance messy -- any time you modify the code by adding a level of blocking you have to modify all enclosed break statements. Miss just one and its mystery bug time. The reason that multilevel breaks are a problem in C is as follows. There are two ways in which labels can be used, (a) as the name of a block, and (b) as a transfer address. Functions use labels to name blocks (the body of the function). Goto's use labels as transfer addresses. The clean way to implement multilevel breaks is to use labelled blocks and name the block you are escaping in the break statement. However labels within function bodies as transfer addresses. You have a conflict of usage here. Of course you could add a block keyword and an escape keyword, e.g. block a { .... block b { .... escape a; } .... } next_statement_after_a; The escape statement transfers control to the next statement after block labelled a. Fine, so far, looks clean, is clean. But are you sure you know where that statement is? Maybe what you want is this: begin a .... begin b .... escape a; end b .... end a where labelled begins and ends delimit blocks. Does this (you should excuse the expression) begin to sound familiar, PL/I fans? Personally I think this approach has its points, but it's starting to stray a fair bit from C. Richard Harter, SMDS Inc.
franka@mmintl.UUCP (Frank Adams) (05/30/86)
In article <852@bentley.UUCP> kwh@bentley.UUCP writes: >>>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. Actually, I was not proposing removing the assignment-has-a-value feature anywhere (although I would not put it into a new language I was designing). The proposal was that it be avoided in if's (and probably while's as well) as a coding standard. That is, it would be legal, but not recommended. In fact, I only use the results from an assignment in two cases. One is to assign the same value to multiple variables, and the other is in the if/while case under discussion here. (Yes, I also normally use "if ((v = e) != 0)"). I may stop using it in this latter case, in favor of the comma operator as described above. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
franka@mmintl.UUCP (Frank Adams) (05/30/86)
In article <450@cad.BERKELEY.EDU> faustus@cad.UUCP writes: [Concerning andif] >I think this looks cleaner, but in any case it isn't an often-encountered >situation and the semantics aren't obvious. There is no disputing matters of taste. I find it is an often-encountered situation, and that the semantics are obvious. >You can write arbitrarily large macros by putting backslashes at the end of >lines. This is ugly but it works. This doesn't let you use "#if" in the body of the macro, as my example would require. To fully explicate, my example would be: #begdef copy(to, from, number) #if sizeof(from) % WORD_SIZE == 0 copyword(to, from, number * sizeof(from) / WORD_SIZE) #else strncpy(to, from, number * sizeof(from)) #endif #enddef > > Confusing "=" and "==" in if statements is a common mistake. If "=" is not > > a legal operator, this error becomes very rare. > >It's also an extra character to type. If you are prone to this sort of >error, just run your code through grep if | grep = | grep -v == ... Thanks but no thanks. If one added a separate step to the compilation process for each type of relatively common error, nothing would ever get done. Again, please note that I did not propose outlawing "=" as a default -- you would have to specify an option to exclude it. > > This is the whole point of having a standard. It gives you some assurance > > that compilers which use the features will be available. > >If the standard has all the things you enumerate, not many people will follow >it and it will be worse than no standard at all. This is not consistent with the experience in promulgating standards for other languages. FORTRAN 77 differs from the old standard rather more than the relatively modest set of changes I proposed; it has been widely adopted, essentially all new FORTRAN compilers adhere to the standard, and such compilers have been made available for most machines still in use on which an older compiler is available. Again, I want to emphasize that my proposals are not things to be included in the current standard (X3J11), but the next one. It is both too late to include changes of this magnitude in that standard, and inappropriate to make this kind of change in the initial standardization of the language. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
ken@njitcccc.UUCP (Kenneth Ng) (05/31/86)
In article <963@h-sc2.UUCP>, augart@h-sc2.UUCP (augart) writes: > >>> 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. > >>Why would you want to use it? > >When your macro won't fit on a line, and/or you want to use #if's etc > >as part of the macro, obviously. > > If your macro won't fit on a line, you can already handle this problem by > finishing off each line except the last with a backslash. > The other addition would be a win, though. C will not allow you to put #if's into a multiple line macro, the backslash only allows you to continue the same line on the next line. It does NOT allow you to start another line. -- Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken bitnet(prefered) ken@njitcccc.bitnet New Jersey Institute of Technology Computerized Conferencing and Communications Center Newark, New Jersey 07102 Vulcan jealousy: "I fail to see the logic in prefering Stonn over me" Number 5: "I need input"
ark@alice.UucP (Andrew Koenig) (05/31/86)
> I would rather see C++ and Concurrent C making their way > into the ANSI standard, but, if it is unfeasible, at least > their usefull additions to the "old C" should see the > world. No, no, NO! The purpose of a standards committee is to codify current practice, not to engage in wholesale language redesign. C++ is an evolving language. Its present form should NOT be frozen into something like ANSI C.
tainter@ihlpg.UUCP (Tainter) (05/31/86)
> Why not use the Ada style of putting a label before the loop body - it's > like giving a name to the loop: > complicated_loop: for(;;) { > {{{{{ > break complicated_loop; > }}}}} > } > No, it's not really much different from a goto. > Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew It is that little bit different though. And it is a definate WIN! When you see a "break <label>" you know the label is on an enclosing block and not just anywhere as in "goto <label>". It alsos provides "continue <label>" with little extra cost. I want BOTH label uses! But this causes an interpretation problem. either: <label> : for () ..... becomes ambiguous: labels loop or is freestanding label? You can resolve this by using <label> : ; for() ..... as a free standing label. or: <label> : for () ..... has both meanings: for goto it is free standing(i.e. restarts the loop) and for break/continue it labels the loop. This should be fairly easy to add to a C derived(*) compiler. --j.a.tainter (Gods answer to lonely microcomputers) * derived because once you starting adding things is it really the same language. I propose we call this language ceder for C DERived since these changes would *spruce* up the language a bit. :-)
cudcv@daisy.warwick.UUCP (Rob McMahon) (06/01/86)
In article <450@cad.BERKELEY.EDU> faustus@cad.UUCP writes: >In article <1497@mmintl.UUCP>, franka@mmintl.UUCP writes: > > > Confusing "=" and "==" in if statements is a common mistake. If "=" is not > > a legal operator, this error becomes very rare. > >It's also an extra character to type... > Are you suggesting we all use single character variable names, or maybe {letter}{digit} when we need more than 26 ? I think phasing in ":=" over a number of years is an excellent idea, first providing a switch to turn on warnings about "=", then always warning, then maybe giving errors. The trouble is "if (a = f())" is just too useful, if you could write "if (a := f())" it becomes readable too (".. a becomes equal to ..." instead of "... a equals ..."). -- UUCP: ...!mcvax!ukc!warwick!cudcv JANET: cudcv@uk.ac.warwick.daisy ARPA: cudcv@daisy.warwick.ac.uk PHONE: +44 204 523037 Rob McMahon, Computer Unit, Warwick University, Coventry CV4 7AL, England
greg@utcsri.UUCP (Gregory Smith) (06/01/86)
In article <1514@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <852@bentley.UUCP> kwh@bentley.UUCP writes: >>>>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, I was not proposing removing the assignment-has-a-value feature >anywhere (although I would not put it into a new language I was designing). >The proposal was that it be avoided in if's (and probably while's as well) >as a coding standard. That is, it would be legal, but not recommended. > Somebody mentioned that Lint could warn about using an assignment value in a boolean context - unless you said /* BOOLEUSED */. I think the warning is a good idea, but the new special comment is not. You can just as easily write ( (v=e)!=0 ) and get same code on any non-silly compiler. ( Note I did not say "good optimizing compiler", which are widely believed to be capable of witchcraft :-) ). ( v=e, v ) would probably get you the same code, too - ditto ( v=e, v!=0). The comma-less version may be a mite faster in some cases. The presence of a 0 encourages the programmer to be explicit as to what kind of zero is being used: while( p=p->link, p != NULL ){ ... I wouldn't mind a compiler warning if an assignment op were used in *any* boolean context ( including being the operand of !, ||, && , and the expr. before a ? ). Note that boolean context is inherited by the RHS of a ',' and by e2 and e3 in e1?e2:e3. -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
mwm@ucbopal.berkeley.edu (Mike Meyer) (06/02/86)
In article <1518@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >This is not consistent with the experience in promulgating standards for >other languages. FORTRAN 77 differs from the old standard rather more than >the relatively modest set of changes I proposed; it has been widely adopted, >essentially all new FORTRAN compilers adhere to the standard, and such >compilers have been made available for most machines still in use on which >an older compiler is available. The thing about F77 (and FIV vs FII) is that most of the features in the F77 standard had already been implemented - or at least something similar to them - in most compilers already. The standard was, as someone (many someones?) keep saying, an effort in standardizing existing practices, not creating new ones. The most significant change that wasn't in general use was the 0-iteration do loop; the change that caused the most howling (at least the most amusing howling) was not printing a field of "*"'s for values that wouldn't fit in the format field specified. I think that your proposed changes are more serious than those two cases. In light of this, the way to get people to adopt your proposed extensions (or anyone elses, for that matter!) is to add them to a C compiler, make it generally available, and convince people to use those features. Having a good book that teaches C + those features will help a lot, too. <mike
rlb@zaiaz32.UUCP (06/02/86)
> > provided that the two expressions evaluate to whatever a boolean int is > locally (1 or -1). {BTW I usually use set_me_true = (1 == 1)} > This worries me, much the same as when I see someone code: #define FALSE 0 #define TRUE !FALSE Makes me think that the person writing may really not know that a C "boolean" expression (expression formed with the logical/relational operators) is *defined* to be either 1 or 0. ...ihnp4!zaiaz!rlb -Ron Burk
eric@chronon.UUCP (Eric Black) (06/03/86)
In article <2600059@ccvaxa> aglew@ccvaxa.UUCP writes: > >~> Multi-level breaks > >Why not use the Ada style of putting a label before the loop body - it's >like giving a name to the loop: > > complicated_loop: for(;;) { > {{{{{ > break complicated_loop; > }}}}} > } > >No, it's not really much different from a goto. Sure it's different! The keyword "break" conveys much more information; it implies an exit from some sort of loop or other shapely control flow construct (what shape is "switch"?), whereas "goto" can mean just about anything, including jumping INTO another control construct. Having a name attached to it helps make it clear which control construct is being exited. There is no way that "break" can land you in the middle of another block, or a "for" loop, or "do...while", but a "goto" could. This makes it easier to understand what is written. The question is, just how much semantic content is to be attached to that name? I assume the compiler should complain if the name can't be found as a valid label in a containing control construct; the name is not just a comment for human consumption. firstloop: while(1) { /* something */ } secondloop: while(1) { /* something else */ break firstloop; } But should the compiler FORCE the break to refer to the construct which is named? outerloop: while(1) { /* something */ innerloop: for(i=0; i<IMAX; i++) { /* something else */ break outerloop; } } This is something which is kind of awkward to express now without either a goto (horrors!) or setting some flag which is examined inside the outer loop but outside the inner one. I like the idea of the compiler understanding the name attached to a break statement, and warning if it thinks you're doing something you don't expect ("do what I mean, not what I say!"); I think the pre-processor should inspect and *enforce* similar labels on #if/#ifdef blocks as well. But again, I'm not at all sure that it should do more than flag apparently out-of-place labels, or change the semantics of the program if it were identical except without the attached labels. Scream about what it thinks I said, yes, but don't presume to do what it thinks I meant! -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric
franka@mmintl.UUCP (Frank Adams) (06/04/86)
In article <1617@ecsvax.UUCP> bet@ecsvax.UUCP (Bennett E. Todd III) writes: >In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >> if (!(A)) goto _Z; >> X >> if (B) { >> Y >> } else { >>_Z: >> Z >> } > >Why not use > > if (A) { > X > if (B) { > Y > } > } else { > Z > } Because this doesn't execute Z when A is true but B is false. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
barmar@mit-eddie.MIT.EDU (Barry Margolin) (06/04/86)
In article <167@zaiaz32.UUCP> rlb@zaiaz32.UUCP writes: >> >> provided that the two expressions evaluate to whatever a boolean int is >> locally (1 or -1). {BTW I usually use set_me_true = (1 == 1)} >> > >This worries me, much the same as when I see someone code: > > #define FALSE 0 > #define TRUE !FALSE > >Makes me think that the person writing may really not know that a C >"boolean" expression (expression formed with the logical/relational operators) >is *defined* to be either 1 or 0. I think your worries are unfounded. The difference between (1 == 1) and 1 is that the former indicates to human readers of the code that the expression is being used for its truth value. In the statement var = 1; the reader is likely to assume that var is going to be used arithmetically. To calm your fears about the #define's, let me try a little satirical analogy: --------- This bothers me, much the same as when I see someone code file = fopen (...); Makes me thing that the person writing may really not know that the standard I/O library function "fopen" is *defined* to return a file. ---------- The point of the analogy is that there is nothing wrong with using menmonic names for things. While it may be true that C defines 0 and 1 to be falsity and truth, it doesn't hurt to use macros to say what you really mean. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
david@ztivax.UUCP (06/04/86)
PLEASE don't make := the assignment operator!!!!! [shift][:] [=] is a pain, slow, it hurts my fingers :-) and it is error prone if you type fast. The assignment operator is easily the most common, and so it should be one character, unshifted. If mixing up "=" and "==" is a big problem, make it a warning generated by the compiler. This is very easy to do, just like inserting semicolons or parens, or deleting extra parens (Obviously, making such changes often invalidates the code). True, extraneous error messages are a pain, but at least you get warned. Better: add them to lint, and leave C alone.
steffen@ihuxy.UUCP (Joe Steffen) (06/04/86)
> >>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)".) > >> > > > Somebody mentioned that Lint could warn about using an assignment value > in a boolean context - unless you said /* BOOLEUSED */. I think the > warning is a good idea, but the new special comment is not. You can just > as easily write ( (v=e)!=0 ) and get same code on any non-silly compiler. > > I wouldn't mind a compiler warning if an assignment op were used in > *any* boolean context ( including being the operand of !, ||, && , and > the expr. before a ? ). Note that boolean context is inherited by the > RHS of a ',' and by e2 and e3 in e1?e2:e3. I added a simple check to buildtree() in the pcc compilers I support to warn of and = op directly under a CBRANCH op, which is used by if, while, and the middle expression in a for statement. This caught many latent bugs in our project's code, many which were of the form if (rc = f() != 0) The warning can be ignored on while (*p++ = *q++) or preferably changed to while ((*p++ = *q++) != 0) for clarity, as stated above. Unfortunately many pcc compiler generate a useless compare instruction for the latter, since the condition codes are already set by the move instruction on many machines. With another simple change to optim() in the compiler to remove the != 0 under a CBRANCH op, I solved this objection to adding the != 0, and the compiler generates less code! -- Joe Steffen, AT&T Bell Labs, Naperville, IL, (312) 979-5381
throopw@dg_rtp.UUCP (Wayne Throop) (06/05/86)
> franka@mmintl.UUCP (Frank Adams) >> faustus@cad.UUCP >>You can write arbitrarily large macros by putting backslashes at the end of >>lines. This is ugly but it works. > > This doesn't let you use "#if" in the body of the macro, as my example would > require. To fully explicate, my example would be: > > #begdef copy(to, from, number) > #if sizeof(from) % WORD_SIZE == 0 > copyword(to, from, number * sizeof(from) / WORD_SIZE) > #else > strncpy(to, from, number * sizeof(from)) > #endif > #enddef Along with multi-line-ness, this example has snuck in a *very* large change in the language. In particular, #if sizeof(from) In order to evaluate this, the preprocessor would need to know (oddly enough) the size of "from". Since the preprocessor currently does not even know full C syntax, this is a *very* radical change in the language. -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw
faustus@cad.BERKELEY.EDU (Wayne A. Christopher) (06/05/86)
In article <1518@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: > This doesn't let you use "#if" in the body of the macro, as my example would > require. To fully explicate, my example would be: > > #begdef copy(to, from, number) > #if sizeof(from) % WORD_SIZE == 0 > copyword(to, from, number * sizeof(from) / WORD_SIZE) > #else > strncpy(to, from, number * sizeof(from)) > #endif > #enddef You can't use sizeof in a #if anyway. You can only use constants and pre-defined cpp symbols. (Pardon me if you're talking about a different compiler -- I'm using 4.3 cc.) It is not clear what you are trying to do with your macro anyway. Is 'from' always a char *? If so you don't need the sizeof. Can it be a pointer to anything? In that case you don't want to use strncpy, and you would want to write sizeof (*from), if it worked. In most of the cases where you want to do something like this, you can put the #if's outside of the #define's anyway, and if you can't, the macro is probably complex enough to make into a function. > >It's also an extra character to type. If you are prone to this sort of > >error, just run your code through grep if | grep = | grep -v == ... > > Thanks but no thanks. If one added a separate step to the compilation > process for each type of relatively common error, nothing would ever get > done. Again, please note that I did not propose outlawing "=" as a > default -- you would have to specify an option to exclude it. I meant that suggestion as a sort of "cleaning up a several months' worth of code and finding little bugs" device. I would say that in the normal process of finding bugs you will locate = / == problems pretty quickly, and after you use the language for a while you just learn not to do things like that. I personally think that := is sort of ugly anyway... If you really want a lot of extra checking, soup up lint a bit... You don't have to get your own private lint through any standards committees... Wayne
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (06/05/86)
In article <2176@mit-eddie.MIT.EDU> Barry Margolin writes: >I think your worries are unfounded. The difference between (1 == 1) and >1 is that the former indicates to human readers of the code that the >expression is being used for its truth value. In the statement > var = 1; >the reader is likely to assume that var is going to be used >arithmetically. Actually, the *real* difference between "(1 == 1)" and "1" is that the former causes lint to complain that a constant is being used in a conditional context *every time you use it*. This is no fun at all. I mean, really. Isn't var = TRUE; just as descriptive? Why not do that, with # define TRUE 1 # define FALSE 0 Ken Arnold
franka@mmintl.UUCP (Frank Adams) (06/05/86)
In article <774@jade.BERKELEY.EDU> mwm@ucbopal.UUCP (Mike Meyer) writes: >The thing about F77 (and FIV vs FII) is that most of the features in >the F77 standard had already been implemented - or at least something >similar to them - in most compilers already. This is not true. The biggest change was the IF (...) THEN ... ENDIF construct. I don't know of *any* compiler which supported this before the standard came out; certainly it was not common. This change was completely upward compatible; but so are my proposed changes. (Well, not completely so in all cases, but almost. Some of them reserve new keywords.) Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
mkr@mmm.UUCP (MKR) (06/06/86)
In article <3542@reed.UUCP> kab@reed.UUCP (Kent Black) writes: >In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >>>> o An andif clause for if statements. >>You would write: >> if (A) { >> X >> } andif (B) { >> Y >> } else { >> Z >> } > >Which is equivalent to: > > if (A) { > X; > if (B) { > Y; > } > } else { > Z; > } > Correct me if I'm wrong ( :-) ), but the second example is not actually equivalent to the first. In the first I assume that Frank means that Z gets executed only if A *and* B are false. In the second, Z gets executed if A is false, regardless of B. --MKR
zben@umd5.UUCP (Ben Cranston) (06/07/86)
In article <8200005@ztivax.UUCP> david@ztivax.UUCP writes: >PLEASE don't make := the assignment operator!!!!! >[shift][:] [=] is a pain, slow, it hurts my fingers :-) and >it is error prone if you type fast. >The assignment operator is easily the most common, and so it >should be one character, unshifted. Clearly "=" should remain the assignment operator. We should replace all testing with the extended syntax: ... switch (a:b) { case <: isgreater; break; case =: isequal; break; case >: isless; break; default: yell("this cannot happen!\n"); } ... I would have used (a?b) but it was already taken... :-) -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
henry@utzoo.UUCP (Henry Spencer) (06/08/86)
> ... The biggest change [in F77] was the IF (...) THEN ... ENDIF > construct. I don't know of *any* compiler which supported this before the > standard came out; certainly it was not common... It was in almost every Fortran preprocessor in existence, of which there were dozens. There was a lot of coding experience using them. For most of its users, a preprocessor counts as part of the compiler. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
faustus@cad.BERKELEY.EDU (Wayne A. Christopher) (06/09/86)
In article <1550@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: > >The thing about F77 (and FIV vs FII) is that most of the features in > >the F77 standard had already been implemented - or at least something > >similar to them - in most compilers already. > > This is not true. The biggest change was the IF (...) THEN ... ENDIF > construct. I don't know of *any* compiler which supported this before the > standard came out; certainly it was not common. You mean that before 1977 there was no if statement in fortran? Sounds like a fun language to work with... :-) Wayne
davidsen@steinmetz.UUCP (Davidsen) (06/09/86)
I resisted commenting on the original or followup of this, but I can't resist on this round! In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <5498@alice.uUCp> ark@alice.UUCP writes: >>Frank Adams says: ... >>> 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. >> >>What would it mean to use these on the left of an assignment, >>and why would you want to use it? > >It would mean what it usually means. If "\/" is the minimum operator, then >"a \/= b" would mean "a = a \/ b". I find it hard to believe that anyone >with any programming experience would need to ask why you would want to use >it. Use of the <binary operator-assignment> feature is not the same thing as "use left of assignment". The original request was poorly stated. As for "most but not all C operators are", please state which binary operator is not allowed to be used with assignment. >>> o An andif clause for if statements. >> >>What does it do and how would you use it? > >You would write: > > if (A) { > X > } andif (B) { > Y > } else { > Z > } > >This is equivalent to: > > if (!(A)) goto _Z; > X > if (B) { > Y > } else { >_Z: > Z > } *you* might do that, but most people would nest the "if (B)" after the "if (A)". if (A) { X if (B) { Y } } else { Z } ... discussion of #begdef deleted ... > >>> o A typeof operator, similar to sizeof. >> >>What would its value be? Why would you want to use it? > >"typeof(x)" would be a type, which is the type that x was declared as. This >is for use primarily in macros. I mentioned this to a number of people at the X3J11 meeting in Seattle. It sounds neat, but is really pretty esoteric. Nobody could think of a really great use for it, and trivial uses don't justify a change to the language. >>> o := as a synonym for =. Compilers could have an option to permit := only. >> >>Why bother? > >Confusing "=" and "==" in if statements is a common mistake. If "=" is not >a legal operator, this error becomes very rare. I once did this in a language called IMP (based on "B"), and it saved no end of pain. However, I can't see changing the language to provide a feature which can be provided by a preprocessor filter (I may even write one now that the idea strikes). >>> o Permit a continue statement in switch, meaning that the next label should >>> be fallen through to. Compilers and/or lint could produce when a program >>> falls through without a continue statement. >> >>A continue statement is already legal in a switch, as long as that >>switch is enclosed in a for or while. It means go on to the next >>iteration of the enclosing loop. Are you proposing to change this? > >Yes. You would break so many existing programs that you should wash your mind out with soap for even thinking this. X3J11 was very careful to make *additions* where appropriate, rather than break existing programs. ... discussion of multi-level break deleted ... >>> o Elimination of the eight-character truncation of internal variable names >>> done by some compilers. (This may be in the current spec; I haven't read >>> that document.) The entire length of a variable name should be significant. >> >>Most compilers do this already. > >So let's make it part of the standard, and those of us who like to write >portable code can start using it. It is obvious that you haven't read the standard. The new length is 31 characters for internal names. Using *all* characters would allow a valid program which had identifiers longer than the addressing space of some machines. X3J11 also limited the length of macros and number of levels of #include, so that "real C" could be implemented on reasonable sized machines. ... discussion of how wonderful standards are deleted ... > >Frank Adams ihnp4!philabs!pwa-b!mmintl!franka >Multimate International 52 Oakland Ave North E. Hartford, CT 06108 I believe the original posting also mentioned complex as a type, currently in C++, desirable in C. Larry Rossler suggested that in an early X3J11 meeting, but the response was underwhelming from most of the committee. I personally feel that (a) this would get FORTRAN out of my life at last, and (b) no one can convince me that it's too big, since I had complex in FORTRAN on my CP/M machine with a total of 48k. If there is a followup C committee for "C90" or whatever, I hope to be able to participate again. Disclaimer: if I have misquoted anyone on the X3J11 committee or failed to quote them, the fault is mine. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen / sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"
davidsen@steinmetz.UUCP (Davidsen) (06/09/86)
In article <852@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <1462@mmintl.UUCP> mmintl!franka (Frank Adams) proposes: >... >>>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?) > Actually, in sorts I might want a ++ operator on at least one side of the swap operator frequently. Issues which occur to me: 1) The swap operator should correctly handle swap between dirrering types, such that correct type conversion is done in both directions. 2) The swap operator should evaluate the address of both sides only once, like +=, so that self modifying expressions may be used on either or both sides. 3) What would it return? All other binary operators, including assignment, return a defined value and type. Which side of the operator would be returned, and why not the other? I suggest that this is a *perfect* use for the void type, and that the operator not return any value (explicitly). 4) I reject the argument that the same thing can always be done inline. A swap operator would improve readability and (possibly) performance. The people who make this argument probably would have rejected "while", saying that we already have "goto" and "if". I am not really pushing to get this into the current standard, because the time for major changes has passed, and this certainly does not address a burning need or major shortcoming of the language. I *do* think it should be considered for the next standard. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen / sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"
levy@ttrdc.UUCP (Daniel R. Levy) (06/10/86)
In article <532@cad.BERKELEY.EDU>, faustus@cad.BERKELEY.EDU (Wayne A. Christopher) writes: >In article <1550@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: >> >The thing about F77 (and FIV vs FII) is that most of the features in >> >the F77 standard had already been implemented - or at least something >> >similar to them - in most compilers already. >> This is not true. The biggest change was the IF (...) THEN ... ENDIF >> construct. I don't know of *any* compiler which supported this before the >> standard came out; certainly it was not common. >You mean that before 1977 there was no if statement in fortran? Sounds like >a fun language to work with... :-) > Wayne Read the posting more carefully. Fortran generally did not support IF (logical_expression) THEN statements [ELSE IF (logical_expression) THEN more statements ELSE yet more statements] END IF before the advent of Fortran-77. It sure as heck DID support IF (logical_expression) statement (where "statement" was exceedingly likely to be a GOTO (-: ) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
rgh%inmet.uucp@BRL.Arpa (06/10/86)
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: Frank Adams <franka%mmintl.uucp@BRL.ARPA> Subject: Re: What should be added to C To: info-c@BRL-SMOKE.ARPA Return-Path: <info-c-request@BRL.ARPA> Redistributed: Xerox-Info-C^.x@XEROX.ARPA Received: from BRL-AOS.ARPA by Xerox.COM ; 02 JUN 86 14:18:54 PDT Received: from brl-smoke.arpa by AOS.BRL.ARPA id a015862; 2 Jun 86 17:05 EDT Received: from USENET by SMOKE.BRL.ARPA id a004718; 2 Jun 86 16:33 EDT Newsgroups: net.lang.c Message-ID: <1514@mmintl.UUCP> Posted: Fri May 30 07:58:19 1986 GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV In article <852@bentley.UUCP> kwh@bentley.UUCP writes: >>>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. Actually, I was not proposing removing the assignment-has-a-value feature anywhere (although I would not put it into a new language I was designing). The proposal was that it be avoided in if's (and probably while's as well) as a coding standard. That is, it would be legal, but not recommended. In fact, I only use the results from an assignment in two cases. One is to assign the same value to multiple variables, and the other is in the if/while case under discussion here. (Yes, I also normally use "if ((v = e) != 0)"). I may stop using it in this latter case, in favor of the comma operator as described above. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
guy@sun.uucp (Guy Harris) (06/11/86)
> I believe the original posting also mentioned complex as a type, > currently in C++, desirable in C. C++ doesn't have "complex" as a built-in type. It has the ability to add new types to the language, the ability to overload operators, and the ability to have inline functions; they were used in a *tour de force* demonstration of how you can "add" "complex" to C++ without changing the compiler or the base language. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
kab@reed.UUCP (Kent Black) (06/11/86)
In article <779@steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes: >In article <1497@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >>In article <5498@alice.uUCp> ark@alice.UUCP writes: >>>Frank Adams says: >>>> o An andif clause for if statements. >> >>You would write: >> >> if (A) { >> X >> } andif (B) { >> Y >> } else { >> Z >> } >> >>This is equivalent to: >> >> if (!(A)) goto _Z; >> X >> if (B) { >> Y >> } else { >>_Z: >> Z >> } > >*you* might do that, but most people would nest the "if (B)" after the >"if (A)". > > if (A) { > X > if (B) { > Y > } /* if (!B) ??? */ > } else { > Z > } > Yep, I was there among "most people"; unfortunately, it isn't the same code. The original can be rewritten as: if (A) { X; if (B) Y; else goto _Z; } else { _Z: /* this deserves a comment! :-) */ Z; } Flow of control is to 'Z' on (!A) OR (!B). If gotooz are anathema, flags can be used, e.g., aflag = bflag = FALSE; if (A) { aflag = TRUE; X; if (B) bflag = TRUE; Y; } if (aflag == FALSE || bflag == FALSE) { Z; } ----------------- My apologies to Bill Davidsen for not digging out my own posting, to Frank Adams for not reading carefully and to the rest of the net. ----------------- Kent Black (...tektronix!reed!kab)
davidsen@steinmetz.UUCP (Davidsen) (06/12/86)
In article <1006@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >In article <8200005@ztivax.UUCP> david@ztivax.UUCP writes: >> (condensed to "don't make := assignment") > >Clearly "=" should remain the assignment operator. We should replace all >testing with the extended syntax: > >... > switch (a:b) { > case <: isgreater; break; > case =: isequal; break; > case >: isless; break; > default: yell("this cannot happen!\n"); > } >... > I really like this! I don't propose that we use it, but I like it! It reminds me that the only thing I miss in FORTRAN is the arithmetic IF, when I write certain types of quick and dirty comparisons. Perhaps we could also take inspiration from the ? triadic operator and use '$' for a quadradic operator, return different values for <, =, >. i.e. n = (a$b : less() : equal() : greater()); I don't think I'm serious... -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen chinet ------/ sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"
shap@bunker.UUCP (Joseph D. Shapiro) (06/16/86)
In article <788@steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes: >I really like this! I don't propose that we use it, but I like it! It >reminds me that the only thing I miss in FORTRAN is the arithmetic IF, >when I write certain types of quick and dirty comparisons. Perhaps we >could also take inspiration from the ? triadic operator and use '$' for >a quadradic operator, return different values for <, =, >. >i.e. n = (a$b : less() : equal() : greater()); > >I don't think I'm serious... >-- > -bill davidsen Interesting idea, but the syntax may be more consistent as... n = ( (expr) $ less() : zero() : greater() ); where if the expression evaluated as negative, less() would be invoked, etc. I don't think I'm serious either. -- -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Joseph D. Shapiro "He who hesitates Bunker Ramo Information Systems is lunch" ...ittatc!bunker!shap ...decvax!bunker!shap
franka@mmintl.UUCP (Frank Adams) (06/17/86)
In article <779@steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes: >I resisted commenting on the original or followup of this, but I can't >resist on this round! > ~> Min and max operators. > >As for "most but not all C operators are", please state which binary >operator is not allowed to be used with assignment. The original statement was indeed ambiguous. I clarified what I meant in my reply. I see no reason for sarcastic interjections. Binary operators which cannot be used with assignment are "<", ">", "==", "<=", ">=", "!=", "&&", and "||". ~> An andif clause for if statements. >>This is equivalent to: >> >> if (!(A)) goto _Z; >> X >> if (B) { >> Y >> } else { >>_Z: >> Z >> } > >*you* might do that, but most people would nest the "if (B)" after the >"if (A)". > > if (A) { > X > if (B) { > Y > } > } else { > Z > } This is *not* the same. For andif, the else clause is taken if either condition fails. Incidently, I did say that that is how I would *write* the equivalent structure in C. It is an attempt to show relatively directly what flow of control is desired -- but I never jump into a block from outside it. There are in fact a variety of ways to get the effect of this control structure, none wholly satisfactory. These include duplicating the code "Z", various arrangements with boolean variables, and duplicating the evaluation of the conditions "A" and "B". I use various ones, depending on the particular case. The issue of how to represent this structure in existing languages was beaten to death in net.lang not long ago; let's not repeat it the discussion here. ~>A typeof operator, similar to sizeof. > >I mentioned this to a number of people at the X3J11 meeting in Seattle. >It sounds neat, but is really pretty esoteric. Nobody could think of a >really great use for it, and trivial uses don't justify a change to the >language. There are, I think, lots of useful macros which would be possible with this. #define allocate(p) (p) = (typeof *(p))(malloc(sizeof *(p)) for example. There are no major uses except in macros; but I think those uses justify the feature. ~>continue statements in switches to mean that the next label should be ~>fallen through to. I was trying to save adding a new keyword. On further consideration, the compatibility problem of changing the meaning of continue in this context is more serious. So consider the proposal amended to use some other keyword. Possibilities which occur to me are "nobreak", "proceed", "fall through". I'm open to suggestions. ~> Elimination of the eight-character truncation of internal variable names > >It is obvious that you haven't read the standard. As with many other people, I do not find it worth my while to spend the time and money (especially the former) to get a copy of the proposed standard which is many months out of date. >The new length is 31 characters for internal names. This is perfectly adequate. >I believe the original posting also mentioned complex as a type, >currently in C++, desirable in C. No, someone else brought it up later. >Larry Rossler suggested that in an >early X3J11 meeting, but the response was underwhelming from most of >the committee. I personally feel that (a) this would get FORTRAN out of >my life at last, and (b) no one can convince me that it's too big, >since I had complex in FORTRAN on my CP/M machine with a total of 48k. In many ways, I would rather have the ability to define how operators are to be interpreted for defined (structure) types. This would be significantly harder to implement, but it deals with a larger class of problems, and in many ways seems to me to be more in keeping with the C philosophy. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108