gaynor@athos.rutgers.edu (Silver) (03/12/89)
I find the inability to nest comments (in langauges which provide delimited comments) very unfriendly. Whoever came up with the bright idea that this is a `feature'? Probably some lazy language designer who wrote a baby compiler to test a new language, and found that it was slightly easier for him to implement it without nesting, so he defined it thus. A black day. This has led to more bugs than I care to remember or imagine. When was the last time this dead horse was kicked? I think it's time to kick it again, given the number of postings about comments causing errors. Regards, [Ag] gaynor@rutgers.edu
vic@zen.UUCP (Victor Gavin) (03/13/89)
In article <Mar.11.18.24.04.1989.18285@athos.rutgers.edu> gaynor@rutgers.edu writes: >I find the inability to nest comments (in langauges which provide delimited >comments) very unfriendly. Whoever came up with the bright idea that this is a >`feature'? I've never heard anyone state that this type of comment is a `feature'. That's like saying that passing parameters by reference is a `feature', because the languages you've used have never done that. > Probably some lazy language designer who wrote a baby compiler to >test a new language, and found that it was slightly easier for him to implement >it without nesting, so he defined it thus. A black day. Don't be stupid. Just coz you don't like comments this way is no reason to be so critical of the people that design and write languages. If you don't like the facilities offered by a particular language then change to a language which works the way you want it to. Alternatively you can write a pre-processor to strip out comments the way you like -- just don't expect much in the way of portability! > This has led to more >bugs than I care to remember or imagine. When was the last time this dead >horse was kicked? I think it's time to kick it again, given the number of >postings about comments causing errors. People have problems in any language that they do not understand/comprehend, that's why there a lot of people who are able to make money teaching others how to program. I program in C (which I would guess is the language that you are having a go at) and find that I can manage to write comments without making the mistakes you seem to. >Regards, [Ag] gaynor@rutgers.edu vic
jlg@lanl.gov (Jim Giles) (03/15/89)
From article <1543@zen.UUCP>, by vic@zen.UUCP (Victor Gavin): > People have problems in any language that they do not understand/comprehend, > that's why there a lot of people who are able to make money teaching others > how to program. People also have problems in languages that they DO understand/comprehend! The issue here is how to minimize the occurance/severity of such problems for BOTH classes of programmers. There is a related issue: how hard is it for a new user to learn the language - particularly its pitfalls/limitations. /* I also don't have much problem with the C type */ /* of comments. This is because I always terminate */ /* comments before the end of a line (like now). */ // Or better yet, I use a language like C++ which // always terminates comments beginning with '//' // at the end of a line - automatically. In addition, I always use ifdef-type macro sequences to eliminate code rather than commenting it out. I do these things because I have learned that it is not safe to do otherwise. The comment syntax which requires explicit termination of comments _IS_ more difficult to learn to use safely. The safe use of the construct is also (marginally) more difficult in actual use. It is doubtful that anyone designing a new language would consider the old-fashioned C-like syntax to be desireable.
chase@Ozona.orc.olivetti.com (David Chase) (03/15/89)
In article <10460@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >// Or better yet, I use a language like C++ which >// always terminates comments beginning with '//' >// at the end of a line - automatically. ... >It is doubtful that anyone designing a new language would >consider the old-fashioned C-like syntax to be desireable. Sigh. At the risk of sounding like a broken record (not that that stops anybody else on the net), there were languages before C (hence older) and they used the // this is a comment to EOL style of comments. Specifically, there was BCPL, C's grandparent. I have often wondered why some features present in BCPL were removed in C; I construct my own explanations, but they tend to be unflattering to the designers of C. BCPL had its warts, of course, but I often think that they threw out the baby and kept the bathwater. Examples of "nice" things discarded include: * // comments * VALOF <block> expressions For example, here's how to use a "case" statement within an expression: VALOF SWITCHON x INTO $( CASE 'a': CASE 'e': CASE 'i': CASE 'o': CASE 'u': RESULTIS vowel CASE 'y': RESULTIS sometimes DEFAULT: RESULTIS consonant $) (This has reappeared within GCC, I believe) * extended relational tests (e.g. '0' <= ch <= '9') * many fewer parentheses (at the expense of added keywords, but it was a lot nicer to read) * good generic types (actually, only one type, but it includes pointers, integers, procedures, you name it) * :=/= instead of =/== This is a matter of taste, but the character-counting justifications never made much sense to me, especially since BCPL also used = for initialization, allowed elision of redundant semicolons, and permitted multiple assignments. Thus, int a = 1; int b = 2; int c = 3; would be rendered as LET a,b,c = 1,2,3 If a variable's value were subsequently changed, then := would be used. For example, a := b + c * cleaner syntax for function definitions (VALOF helps here) For example, LET min2(a,b) = a < b -> a,b AND min3(a,b,c) = a < b -> min2(a,c), min2(b,c) AND abs(a) = a < 0 -> -a,a I just defined three functions; you can all construct their C versions and compare. I have always wondered what caused the designers of C to leave all this fine stuff out; it's not like the BCPL compiler was a pig, and few of these features had any real effects on portability or efficiency (the generic single type is apparently the biggest headache). Enquiring minds want to know what the reasoning was behind the choices made for C. David
gvcormack@watdragon.waterloo.edu (Gordon V. Cormack) (03/15/89)
The lack of nested comments is an artifact of the conventional way of building compilers using a finite state scanner and a context-free parser. It is difficult (very difficult) to recognise nested comments with a finite state scanner. Dan Salomon and I have a paper in Sigplan 89 PLDI suggesting that finite state scanners be eliminated. --------- With modern text editors, is there really any excuse for bracketed comments? I think end-of-line is a perfect comment terminator. Then nesting becomes a non-issue. -- Gordon V. Cormack CS Dept, University of Waterloo, Canada N2L 3G1 gvcormack@waterloo.EDU gvcormack@uwaterloo.CA gvcormac@water.BITNET
holt@turing.toronto.edu (Ric Holt) (03/15/89)
> >I do these things because I have learned that it is not safe to >do otherwise. The comment syntax which requires explicit termination >of comments _IS_ more difficult to learn to use safely. The safe >use of the construct is also (marginally) more difficult in actual >use. It is doubtful that anyone designing a new language would >consider the old-fashioned C-like syntax to be desireable. There is no doubt that errors from unclosed comments are difficult to spot and that they occur often enough in practice. The design of the commenting convention in Turing had as a goal to avoid this problem and to minimize the lexical space/confusion of a commenting convention. Hence, comments begin with % and run to the end of the line, as in: % Here is a comment %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % % % % Block comment % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% var x : real % Comment at end of a line x := 9.7 % loop % % A nested comment % x += .03 % exit when sqrt(x) > 503 % end loop The last five lines illustrate how you get "nested comments" using %. This is done by having the editor put a % at the beginning of the lines you want commented out. You can, of course, do this repeatedly. And there is no possibility of unclosed comments. Although this is a "complete" convention for commenting, Turing goes ahead and supports, as well, comments of the form /* ... */, but these cannot be nested, to avoid the well known problems with failure to close these.
kers@otter.hpl.hp.com (Chris Dollin) (03/15/89)
Warning: Comment Style Religious Feeling Follows. gaynor@athos.rutgers.edu (Silver) says: | I find the inability to nest comments (in langauges which provide delimited | comments) very unfriendly. Whoever came up with the bright idea that this is | a `feature'? Probably some lazy language designer who wrote a baby compiler | test a new language, and found that it was slightly easier for him to | implement it without nesting, so he defined it thus. A black day. This has | led to more bugs than I care to remember or imagine. When was the last time | this dead horse was kicked? I think it's time to kick it again, given the | number of postings about comments causing errors. Once a language designer has made the blunder of having bracketed comments in the language, the pressure is on him to allow them to be nested. The solution is simple: have only end-of-line comments. Voila! "Any reasonable editor" will be able to block-comment as required. Every comment line will be marked, so the "damn! it was commented out!" errors will go away (he said optimistically). So what's the problem? Regards, | "Every now and again, I can't resist them temptation to indulge Kers. | in an apparently-subjective war."
seeger@poe.ufnet.ufl.edu (F. L. Charles Seeger III) (03/16/89)
In article <12362@watdragon.waterloo.edu> gvcormack@watdragon.waterloo.edu (Gordon V. Cormack) writes: | |The lack of nested comments is an artifact of the conventional |way of building compilers using a finite state scanner and a |context-free parser. It is difficult (very difficult) to recognise |nested comments with a finite state scanner. Isn't it extremely trivial to augment a FSM scanner with a counter to keep track of nesting level? A heuristic nesting limit can be used to catch mismatched comment delimiters. Of course, whatever the limit, it should be settable via the command line. I don't think that I've ever wanted to nest more than two levels deep. Would that be so difficult with a "pure" FSM scanner? Then again, lack of nested comments isn't something that I get excited about. |With modern text editors, is there really any excuse for bracketed |comments? I think end-of-line is a perfect comment terminator. |Then nesting becomes a non-issue. Personally, I like bracketed comments for "commenting out" code (no flames please) and for long, multi-line comments for files and functions. Seems pretty easy to provide both without a significant performance hit. -- Charles Seeger 216 Larsen Hall +1 904 392 8935 Electrical Engineering University of Florida seeger@iec.ufl.edu Gainesville, FL 32611
elg@killer.Dallas.TX.US (Eric Green) (03/16/89)
in article <10460@lanl.gov>, jlg@lanl.gov (Jim Giles) says: > do otherwise. The comment syntax which requires explicit termination > of comments _IS_ more difficult to learn to use safely. The safe > use of the construct is also (marginally) more difficult in actual > use. It is doubtful that anyone designing a new language would > consider the old-fashioned C-like syntax to be desireable. In a recent program, I have code similiar to the following: */ /* table */ int Transitions[NUMSTATE][NUMCLASS] = { /* statenum digit number delimiter quote EOF EOL ... */ /* 0 */ 2, 5, 8, 15, 10, 19, /* 2 */ 4, 19, .... The languages in which I have programmed most are "C", Pascal, various assembly languages, and Lisp/Scheme. The first two have explicit terminators, the latter two make everything between a ";" and EOL a comment. When I do assembler or Lisp I regularly run into situations where I want to imbed a comment into a statement for clarity's sake, and can't do it. So it's sort of like the choice between using "C" and using a higher-level language. "C" is more flexible and powerful for many types of code (e.g. write a device driver in Prolog? Out of your mind!). But that flexibility has a price -- it's a lot easier to make mistakes. As far as language comment style is concerned, it's a matter of wehther you want to pay the price for flexibility or not. If your language is one that'll be used in high-risk situations -- e.g. Ada -- you might decide you DON'T want that flexibility. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | \X/
peter@ficc.uu.net (Peter da Silva) (03/16/89)
In article <39273@oliveb.olivetti.com>, chase@Ozona.orc.olivetti.com (David Chase) writes: > * VALOF <block> expressions I put this back into Small-C as an exercize: a = { switch(x) { ... return vowel; } }; > * many fewer parentheses (at the expense of added keywords, but it > was a lot nicer to read) I don't think this was a bonus. > * :=/= instead of =/== But this definitely was. > * cleaner syntax for function definitions (VALOF helps here) Debatable. > LET min2(a,b) = a < b -> a,b Take your pick: min2(a,b) { return (a < b) ? a : b; } #define min2(a,b) (((a) < (b)) ? (a) : (b)) -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jlg@lanl.gov (Jim Giles) (03/17/89)
From article <7555@killer.Dallas.TX.US>, by elg@killer.Dallas.TX.US (Eric Green): > in article <10460@lanl.gov>, jlg@lanl.gov (Jim Giles) says: >> do otherwise. The comment syntax which requires explicit termination >> of comments _IS_ more difficult to learn to use safely. The safe >> [...] > In a recent program, I have code similiar to the following: */ > > /* table */ > int Transitions[NUMSTATE][NUMCLASS] = { > /* statenum digit number delimiter quote EOF EOL ... */ > /* 0 */ 2, 5, 8, 15, 10, 19, > /* 2 */ 4, 19, .... > > [...] When I do assembler or Lisp I regularly run into > situations where I want to imbed a comment into a statement for > clarity's sake, and can't do it. Please read my original comment again. I only oppose a comment syntax which _requires_ explicit termination. I don't oppose a comment syntax which _allows_ explicit termination so long as the end of record also terminates the comment. My favorite syntax for what you have above would go something like this: ! table int Transitions[NUMSTATE][NUMCLASS] = { ! statenum digit number delimiter quote EOF EOL ... ! 0 !! 2, 5, 8, 15, 10, 19, ! 2 !! 4, 19, .... ! 5 !! .... ! .... Here the comments begin with ! and end with !! or the end of line. This syntax even allows code (that doesn't include !!) to be 'commented out': a = b+c ! x = a*(z+y) ! trailing comment for ( ...) ... Here the second statement was commented out. The extra exclamation point doesn't effect the fact that the comment ends at the end of line. As I say, this only works on lines that don't contain an explicitly termionated comment. But, since I prefer ifdef for removing code, this doesn't matter much. This can't be done with C, of course, since ! is an operator in C. But the C++ syntax ('//') might be extended (terminate comments with '\\' maybe). J. Giles
firth@sei.cmu.edu (Robert Firth) (03/17/89)
One of the things I've wanted to do in almost any of the
programming languages I've used, is comment out in a simple
way a fairly large piece of code, without having to worry
about whether that code itself contains comments.
There are three ways to do this with which I'm familiar
(a) Have a comment introduced by a sentinel and terminated
by end-of-line. One then comments out by inserting
the sentinel in front of every line:
C Debugging code commented out
C
CC Print current value of chipmunk queue
C
C CALL CHQPNT(CHQ)
Most editors have an easy way to do this.
(b) Have comments introduced and terminated by paired sentinels
that strictly nest:
{ BEGIN Debugging code commented out
{ print current value of chipmunk queue }
chipmunk queue print ( chipmunk queue );
Debugging commented out code END }
(c) Use line comments normally and reserve block comments for
commenting out:
/* Debugging code commented out
// print current value of chupmunk queue
ChQ.Print(ChQ)
*/
All of these seem to work moderately well; in a language that permits
none of them I sometimes get very frustrated!mg@notecnirp.Princeton.EDU (Michael Golan) (03/18/89)
Nested comments ? what that piece of code:
/**
printf("/* comment");
**/
How do you overcome such problems using FSM, or any parser ?
I think the "right" solution is to use the language smartly. if you don't
use
/*************** COMMENTED OUT
stuff ...
**************** END ****/
(or #if etc), you are stupid. It is just as easy to write hard-to-read code
with other constructions of the language (ANY language!). So what ?
x = 5 * (x == y<<1)? a:b ;
which is really
x= (5 * ( (x==y)<<1 ) )? a:b ;
(No flames pls if I got it wrong!)
At least for me, I had more problems with the above than with comments.
Languge is just a tool. It is a complex tool and hence non-perfect one. You
must use it wisely. Language designers can not predict bad ways of using
the language they design. One fortune I have seen read like that:
"Nothing can be made foolproof because idiots are such ingenious:"
One more note about "C" comments:
int x,*y ;
x=x/*y ; this is commented out */ ;
Michael Golan
mg@princeton.edubeede@pavo.SRC.Honeywell.COM (Michael Beede) (03/18/89)
>> LET min2(a,b) = a < b -> a,b > >Take your pick: > > min2(a,b) { return (a < b) ? a : b; } > #define min2(a,b) (((a) < (b)) ? (a) : (b)) Of course, these are only moderately similar. Using the latter, what is the result of a = 10; b = 20; c = return min2( a++, b-- ); In the case of a true function, the values of the variables are a=11, b=19, c=10. In the case of a macro, the result is a=12, b=19, c=11. If it looks like a function it should _be_ a function. (Now there's a religious issue for you!) Macros are chiefly used in C to substitue for constants and to make up for a lack of inline functions. Most C programmers would be happy to never see another macro if they could use inline functions. Also, it is a real pain stepping through a macro with a source-level debugger (or for that matter trying to locate a syntax error in a nested macro). On the comment issue, nested comments might be nice, but what would be nicer would be comments with single-character delimiters. It is always frustrating to add something to a program, say inside about 5 levels of braces, like Call_Messy_Patch( 0, i, *(Desc->Func)( Q ) ); /* recover from */ /* missing semi- */ /* colon * / and try to figure out why the compiler insists there is a syntax error on some line 60 past where the change was made. But, of course, REAL PROGRAMMERS LIVE WITH THEIR TYPOS! ;-) Since nearly every ascii character in C is either part of an identifier, a constant, or an operator, I have no suggestion for what that language could use. I guess what we need is a few more types of matching brace kind of characters to go along with <{[()]}>! --- Mike Beede -- Secure Computing Technology Center MN55-7282 Honeywell Systems & Research Center (612) 782-7147 2855 Anthony Lane South - Suite 130 Minneapolis MN beede@src.honeywell.com
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/21/89)
(Actual subject, BCPL syntax) In article <3452@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <39273@oliveb.olivetti.com>, chase@Ozona.orc.olivetti.com (David Chase) writes: >> LET min2(a,b) = a < b -> a,b > >Take your pick: > > min2(a,b) { return (a < b) ? a : b; } > #define min2(a,b) (((a) < (b)) ? (a) : (b)) >-- You are actually missing a certain subtlety here. The BCPL statement when executed assigns the address of the code segment to variable min2. BCPL (at least on the IBM 360 that I used around 1970) linked separate compilation modules in an interesting way: 1. BCPL maintains a global common area with numbered (ugh!) slots. 2. Somewhere in the program is a list of compilation module names. 3. When the program loads, each module gets called in turn. 4. The top level code in each module consists of procedure (and global data declarations) which assign the routine addresses in the common area. 5. The "main" module, which is last in the list, contains the main procedure which now has access to procedures in any module! Pretty clever, heh? Sorta looks a bit like Modula-2? If you are really tricky, you could do something like: temp, min, max := min, max, temp to exchange the functions "min" and "max" anywhere they are used! Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply (And I haven't used BCPL in over 15 years now)
pierson@mist (Dan Pierson) (03/22/89)
In article <7555@killer.Dallas.TX.US>, elg@killer (Eric Green) writes: >The languages in which I have programmed most are "C", Pascal, >various assembly languages, and Lisp/Scheme. The first two have >explicit terminators, the latter two make everything between a ";" and >EOL a comment. When I do assembler or Lisp I regularly run into >situations where I want to imbed a comment into a statement for >clarity's sake, and can't do it. You're probably stuck in assembler, but I sort of question where you'd need such a feature. In Common Lisp, you can either use the matching comment syntax (apply foo #| useless! |# a1 a2) or define your own with the read-macro facility. Some Scheme dialects, such as T, let you do similar things. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com
db@lfcs.ed.ac.uk (Dave Berry) (03/24/89)
In article <18972@srcsip.UUCP> beede@pavo.SRC.Honeywell.COM (Michael Beede) writes: >Macros are chiefly used in C to substitue >for constants and to make up for a lack of inline functions. Most C >programmers would be happy to never see another macro if they could >use inline functions. This would imply that macros were unnecessary in C++, which is not the case (yet). Other typical uses include expressions and declarations parameterised on types, finding the offset of a field in a structure, and implementing bitsets. >If it looks like a function it should _be_ a function. Yes. Down with side-effects! (I assume that was what you meant :-) Dave Berry, Laboratory for Foundations of Computer Science, Edinburgh. db%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!db