minow@decvax.UUCP (Martin Minow) (10/05/84)
Here are some comments on Joe Mueller's recent submission, and a
question on just how # contatenation should work. As you probably
know, I've been hacking at a public-domain cpp that will track most
of the Ansi standard (I've omitted things I believe are erroneous,
as will be noted).
1. Benign redefinition should be allowed without comment -- I usually put
#define TRUE 1
#define FALSE 0
in all of my programs, and have added it permanently to the Decus C
stdio.h file -- seeing it twice with the same (textual) value shouldn't
matter. A different value should cause a warning message, but the
compilation should proceed. (Implementation dependent?)
2. Six-character globals are a way of life on Dec's RSX/RT11/RSTS
operating systems and will stay that way for a while. If you
force a change, it will break the outside environment, which I
don't believe is in the committee's charter.
3. Here are some things that I disagree with in the Standard cpp:
1. undefined token has the value zero (in #if's). Cpp should
print a warning -- or error if the evaluator is intelligent
about statements like:
#if defined (foo) && foo == 0
My cpp prints a warning, as it erroneously evaluates the
entire statement.
2. <backslash><newline> is "invisible" to all processing in
the standard. I regard it as "whitespace" outside of
strings, and hence a token delimiter. This greatly
simplifies accurate error message generation.
3. The standard isn't clear about <form-feed> and <vertical-tab> --
are they everywhere identical to <space>? I.e. may they appear
between the start of a line and the # that introduces a control
statement? The standard is also unclear about the action to be
taken at the end of an include file: is the <eof> a token delimiter?
Does it terminate a line?
4. Just how invisible are comments? For example, are the following
correct?
/* foo */ #ifdef foo
# /* foo */ endif
5. cpp should accept "# <number>" as a synonym for "#line <number>"
so that it accepts its own output format.
6. Some people write
#ifdef foobar
#endif foobar
This should be provided for in the syntax -- or explicitly
rejected.
7. I added __DATE__ to the preprocessor predefineds. It's
useful for embedding debugging status (but not essential).
8. I claim that nested comments /* ... /* ... */ warrant
a warning message -- that is a very common source of
error in the programs I see (and impossible to detect
without a warning message).
Those are all the problems I have (today). Here are some questions
about the new concatenation operation:
1. May it appear anywhere, or only on a #define line?
2. What are the semantics of, say,
#define foo abc # def
Is it (1) "foo"; (2) read "abc"; (3) read '#' and realize we're
expanding a token, so (4) read "def" and glue them together?
If so, what happens when "abc" or "def" are macro's:
#define unique here # __LINE__
3. May the #define token be concatenated:
#define unique # counter __LINE__
4. If I should write:
#define unique_var var # counter
#define counter (counter + 1)
#define another_var var # counter
will cpp "do what I mean?"
Some guidance would be appreciated.
I just added stringization to Decus cpp and discovered something
interesting:
#define print(format, value) printf("Result " "format", value)
print("%d", 123);
My first attempt expanded to
printf("Result " ""%d"", 123);
I've added a hack to strip one level of quotes, but aren't too
happy with it. Note that you just can't omit the argument
quotes as you may want to pass ',' through. Also, is this ok:
print('%d', 123);
In that case, I generate
printf("Result " "'%d'", 123);
without comment.
Here are one or two other suggestions (while I've got your attention):
The committee might consider specifying the core run-time library
(str..., is..., the math routines, and a few others) such that the
compiler may generate in-line code or non-standard calling sequences.
There should be a way to override some or all of this, of course.
This was done for Fortran with no evil effects.
Martin Minow
decvax!minowtrt@rti-sel.UUCP (10/05/84)
Here is a repeat request for a simple but important change to cpp.
MOTIVATION
The number of predefined CPP variables on systems worldwide
is growing weekly. The following innocent program fails to compile
on our Gould system:
grumble()
{
int sel;
sel = selectone();
...
}
The reason is that 'sel' is a predefined CPP variable!
(It is quite difficult for a novice user to figure out what is going wrong.)
Other people will find similar strange problems if they use
variables named 'pyramid', 'sun', and so on. This is ridiculous!
WHAT IS WRONG
A predefined variable is produced with explicit code in cpp,
with the '-Dvax' argument to cpp, or with '#define vax 1'
The result is that 'vax' evaluates to '1', which is fine if
people want to say '#ifdef vax' or (gag me) '#if vax'
but not so hot if you want to compile a portable (hear hear!)
program that happens to use 'vax' as a variable.
THE FIX
We should return to the old days when vax was really 'vax',
unix was really 'unix', and small furry creatures were still single.
Here is a weak attempt at how it might be worded:
The effect of '#define foo foo' and also '-Dfoo' as an option
will be to make 'foo' defined and to evaluate to itself.
Subsequently, foo and defined(foo) will both evaluate to 1
within a #if, foo will be considered defined within a #ifdef
or #ifndef, and foo will have no special meaning elsewhere.
DISCUSSION
This change is minor and would not break any existing programs.
People need no longer live in fear of the 'printf' machine
that is to be announced early next year.
I am not sure if '#define unix unix' should be handled as
a special case (ordinarily it would result in a cpp loop),
or if there is a general fix. For example, what about
#define sun (sun|sel) /* avoids changing '#if sun' everywhere */
I suppose that is a fairly disgusting example.
I am sure the Standards committee can figure something out,
so long as I can continue to use a variable named 'os' without
worrying about whether some compiler somewhere has already spoken for it.
Tom Truscottgeoff@desint.UUCP (Geoff Kuenning) (10/06/84)
From Martin Minow: >2. Six-character globals are a way of life on Dec's RSX/RT11/RSTS > operating systems and will stay that way for a while. If you > force a change, it will break the outside environment, which I > don't believe is in the committee's charter. Oh, that's great. The 11 folx haven't had time yet to fix the RAD50/6-char stuff left over from 65K address spaces, so all the rest of us have to suffer? Thanks! Tell you what, though, why stop there? After all, BASIC was originally defined to allow only TWO-character identifiers, and the second had to be numeric. So, for maximum interlanguage compatibility, we ought to restrict globals to the most restrictive common denominator, which appears to be BASIC. (Oops, I forgot TECO--register names are single characters. So we should restrict all globals to one alphabetic character! This would also simplify writing linkers, since they would only have to provide for a maximum of 26 globals). :-) > 8. I claim that nested comments /* ... /* ... */ warrant > a warning message -- that is a very common source of > error in the programs I see (and impossible to detect > without a warning message). YAY, YAY, YAY, YAY! I have probably lost a full eight hours in the last year due to my habit of typing /* ... *? ... /* ... */ (I'm a bit slow on the shift key at times) and then having to spot it by eye or even with a debugger. This is SO easy to detect, and it is far more often a true error than not. (Although people who comment out commented code by putting /* at the front of the line will get lots of warnings...but they were playing with fire in the first place). -- Geoff Kuenning First Systems Corporation ...!ihnp4!trwrb!desint!geoff
henry@utzoo.UUCP (Henry Spencer) (10/07/84)
> We should return to the old days when vax was really 'vax', > unix was really 'unix', and small furry creatures were still single. > Here is a weak attempt at how it might be worded: > The effect of '#define foo foo' and also '-Dfoo' as an option > will be to make 'foo' defined and to evaluate to itself. > Subsequently, foo and defined(foo) will both evaluate to 1 > within a #if, foo will be considered defined within a #ifdef > or #ifndef, and foo will have no special meaning elsewhere. > > I am sure the Standards committee can figure something out, > so long as I can continue to use a variable named 'os' without > worrying about whether some compiler somewhere has already spoken for it. The committee has already made a partial step towards this. Section 9.2 of the 21 Aug 1984 draft: "If the macro name itself appears during the scanning, it is not replaced." In other words, "#define unix unix" will no longer send preprocessors into infinite recursive plunges, which is the reason why this convention was originally dropped. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jim@ism780b.UUCP (10/08/84)
> 1. undefined token has the value zero (in #if's). Cpp should > print a warning -- or error if the evaluator is intelligent > about statements like: > #if defined (foo) && foo == 0 > My cpp prints a warning, as it erroneously evaluates the > entire statement. I disagree. I've seen plenty of code which does #if foo or #if !foo and I don't think a "-Dfoo 0" should be required. > 2. <backslash><newline> is "invisible" to all processing in > the standard. I regard it as "whitespace" outside of > strings, and hence a token delimiter. This greatly > simplifies accurate error message generation. If <backslash><newline> is allowed everywhere, it should behave the same everywhere, so it can be handled at the lowest possible level. And since it must be ignored in strings, it should be ignored everywhere. > 3. The standard isn't clear about <form-feed> and <vertical-tab> -- > are they everywhere identical to <space>? I.e. may they appear > between the start of a line and the # that introduces a control > statement? The standard is also unclear about the action to be > taken at the end of an include file: is the <eof> a token delimiter? > Does it terminate a line? The System V cpp allows FF and VT before the #, but it does not allow other space there. FF and VT should be allowed at least wherever other whitespace is allowed. Allowing arbitrary space before the # breaks the use of cpp as a general preprocessor, but that is probably not a concern of the committee. > 4. Just how invisible are comments? For example, are the following > correct? > > /* foo */ #ifdef foo > # /* foo */ endif Reiser's cpp is poorly written, and breaks on comments in any surprising place. However, it is hard to think of a syntax which does not make that a bug (except for the case where the # must be the first character on the line). > 5. cpp should accept "# <number>" as a synonym for "#line <number>" > so that it accepts its own output format. Absolutely. The fact that the committee has not allowed for this reveals that they have not spent much time looking at existing cpp implementation or usage. > 6. Some people write > > #ifdef foobar > #endif foobar > > This should be provided for in the syntax -- or explicitly > rejected. I agree; it should be allowed. Also for #else. Arbitrary text should be allowed to the right of the required tokens. > 7. I added __DATE__ to the preprocessor predefineds. It's > useful for embedding debugging status (but not essential). The form __FOO__ should be reserved for preprocessor built-in's, with __FILE__ and __LINE__ required and all other implementation-defined. > 8. I claim that nested comments /* ... /* ... */ warrant > a warning message -- that is a very common source of > error in the programs I see (and impossible to detect > without a warning message). I think the standard allows this warning but does not demand it. This is probably good policy for all warnings, and will encourage implementors to provide the warnings to be competitive. >Those are all the problems I have (today). Here are some questions >about the new concatenation operation: > >1. May it appear anywhere, or only on a #define line? If it appears anywhere, the # introducing a control line becomes syntactically ambiguous. However, that is probably ok. I can't imagine a proper implementation that wouldn't have to do more work to disallow it outside of #defines than to allow it. >2. What are the semantics of, say, > > #define foo abc # def > > Is it (1) "foo"; (2) read "abc"; (3) read '#' and realize we're > expanding a token, so (4) read "def" and glue them together? > If so, what happens when "abc" or "def" are macro's: > > #define unique here # __LINE__ Is white space allowed around the #? That makes the syntax a bit messy; the concatenation operator then becomes "an intermixed sequence of zero or more whitespace characters and one or more #'s". How much whitespace do you have to scan in order to find the #? If the # is allowed in running text, that whitespace would normally be copied, but obviously not if it is followed by a #. I don't see why macros are a problem. The # is just like whitespace in that it delimits a token, but it is not copied to the output. > 3. May the #define token be concatenated: > > #define unique # counter __LINE__ That would require expanding names delimited by #, even when they appear in a position not normally expanded. No big deal, but it doesn't get you much; see below. > 4. If I should write: > > #define unique_var var # counter > #define counter (counter + 1) > #define another_var var # counter > > will cpp "do what I mean?" Of course not; the preprocessor does not do arithmetic, and counter is not expanded at the time of the define. But I agree that the semantics must be fully specified so the behavior of such cases is well-defined. >I just added stringization to Decus cpp and discovered something >interesting: > > #define print(format, value) printf("Result " "format", value) > print("%d", 123); > >My first attempt expanded to > > printf("Result " ""%d"", 123); > >I've added a hack to strip one level of quotes, but aren't too >happy with it. Note that you just can't omit the argument quotes as you may want to pass ',' through. Why not just define it as #define print(format, value) printf("Result " format, value) Certainly the string concatenation should not happen until format is evaluated. >Also, is this ok: > > print('%d', 123); > >In that case, I generate > > printf("Result " "'%d'", 123); > >without comment. I would think that you want print("'%d'", 123); You should consistently require double quotes. If you don't want to require quotes, then you can't allow commas, right parens, /*, etc. in the argument. Trying to have your cake and eat it too by stripping quotes just doesn't cut it. Rememeber that this isn't m4, where the quotes are balanced (`'). > The committee might consider specifying the core run-time library > (str..., is..., the math routines, and a few others) such that the > compiler may generate in-line code or non-standard calling sequences. > There should be a way to override some or all of this, of course. > This was done for Fortran with no evil effects. I agree. It would be nice if there were a way to specify in a header file that a routine is possibly builtin, so lint could complain if you take its address. -- Jim Balter, INTERACTIVE Systems (ima!jim)
ken@turtlevax.UUCP (Ken Turkowski) (10/08/84)
> WHAT IS WRONG > A predefined variable is produced with explicit code in cpp, > with the '-Dvax' argument to cpp, or with '#define vax 1' > The result is that 'vax' evaluates to '1', which is fine if > people want to say '#ifdef vax' or (gag me) '#if vax' > but not so hot if you want to compile a portable (hear hear!) > program that happens to use 'vax' as a variable. > > THE FIX > We should return to the old days when vax was really 'vax', > unix was really 'unix', and small furry creatures were still single. > Here is a weak attempt at how it might be worded: > The effect of '#define foo foo' and also '-Dfoo' as an option > will be to make 'foo' defined and to evaluate to itself. > Subsequently, foo and defined(foo) will both evaluate to 1 > within a #if, foo will be considered defined within a #ifdef > or #ifndef, and foo will have no special meaning elsewhere. > > DISCUSSION > This change is minor and would not break any existing programs. > People need no longer live in fear of the 'printf' machine > that is to be announced early next year. > > I am not sure if '#define unix unix' should be handled as > a special case (ordinarily it would result in a cpp loop), The C preprocessor used to behave as you desire on version 6. I seem to recall documantation that implied that special code was used to prevent infinite looping. -- Ken Turkowski @ CADLINC, Palo Alto, CA UUCP: {amd,decwrl,flairvax,nsc}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/08/84)
Hear, hear! I second Truscott's CPP definition proposal.
joemu@tekecs.UUCP (Joe Mueller) (10/08/84)
> The number of predefined CPP variables on systems worldwide > is growing weekly. The following innocent program fails to compile > on our Gould system: > grumble() > { > int sel; > > sel = selectone(); > ... > } > The reason is that 'sel' is a predefined CPP variable! > (It is quite difficult for a novice user to figure out what is going wrong.) > Other people will find similar strange problems if they use > variables named 'pyramid', 'sun', and so on. This is ridiculous! The ANSI committee has concidered this problem. The current draft will state that predefined macros are implementation defined (They will exist BUT you will be provided with a list of them and what they are defined to be), and all conforming compilers MUST have some way of disabling all predefined macros. This way if your application does not want to use them, you may easily remove them without a never-ending, always changing list of #undef foobar's.
guido@mcvax.UUCP (Guido van Rossum) (10/09/84)
Jim Balter, INTERACTIVE Systems (ima!jim): >I think the standard allows this warning but does not demand it. >This is probably good policy for all warnings, and will encourage >implementors to provide the warnings to be competitive. This is a great discovery! Make everything in the language optional; implementors will provide it to be competitive! -- Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido@mcvax.UUCP "You're right. But you're boring."
thomas@utah-gr.UUCP (Spencer W. Thomas) (10/10/84)
In article <143@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >YAY, YAY, YAY, YAY! I have probably lost a full eight hours in the last year >due to my habit of typing /* ... *? ... /* ... */ (I'm a bit slow on the >shift key at times) and then having to spot it by eye or even with a debugger. >This is SO easy to detect, and it is far more often a true error than not. >(Although people who comment out commented code by putting /* at the front of >the line will get lots of warnings...but they were playing with fire in the >first place). I have been using a program called cchk, which was posted to the net a couple of years ago. It detects nested comments, indentation "errors", if ( a = b ), and so on. I find it very useful for checking for possible typing errors. It even produces a message for if ( a ) if ( b ) something; else something_else; ("else matched to wrong if"). I could post it to the net again, I guess, if there's interest (I've made some local changes dealing mostly with making it work better with make, and changed the error message format to make Gosling's emacs happy). =Spencer
rbt@sftig.UUCP (R.Thomas) (10/10/84)
> The current draft will > state that predefined macros are implementation defined (They will > exist BUT you will be provided with a list of them and what they are > defined to be), and all conforming compilers MUST have some way of > disabling all predefined macros. This way if your application does not > want to use them, you may easily remove them without a never-ending, > always changing list of #undef foobar's. I hope that the standard will allow you to turn off all predefined preprocessor variables, and give an exception list (that your program needs to have). Things like '__LINE__' and '__FILE__' are too good to loose (in certain applications) just because the local C compiler defines 'stack' (in a mistaken attempt to tell you that you are executing on a stack machine, or something...) I don't want to be forced to throw out the baby with the bath water. Rick Thomas
lwall@sdcrdcf.UUCP (Larry Wall) (10/11/84)
In article <12902@sri-arpa.UUCP> Paul Schauble writes: > The most primative linker I can immediately think of coded the >names into a 32 bit word, using 6 characters from an alphabet of 40. >(Isn;t this what the PDP11 does, rather than radix 50??) The beloved RAD50 has an alphabet of 40 characters. Think octal. Larry Wall {allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall
rcd@opus.UUCP (Dick Dunn) (10/11/84)
>... > > 1. undefined token has the value zero (in #if's). Cpp should > > print a warning -- or error if the evaluator is intelligent > > about statements like: > > #if defined (foo) && foo == 0 >... > I disagree. I've seen plenty of code which does > > #if foo > or > #if !foo > > and I don't think a "-Dfoo 0" should be required. Looks like you've seen plenty of code which is confused about the difference between testing whether a symbol is defined and testing its value. That's a fairly fundamental confusion, and it's easily remedied by using ifdef/ifndef. I don't see why poor usage becomes an argument in the standardization process. (Well, in reality I do; I wish I didn't:-) -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Relax...don't worry...have a homebrew.
dat@hpcnoe.UUCP (dat) (10/14/84)
How about this approach: if the program uses it, it loses it's
previous meaning if not define EXPLICITELY in the user program. That
way the following would work;
lets say 'alpha' is a predefine cpp variable. Then the
program;
main()
{
printf("%s", alpha); /* or whatever */
}
would still function as usual, whereas the program;
main()
{
float alpha;
printf("%f", alpha);
}
would also succeed.
I would rather have the COMPILER and SYSTEM do the work than the
programmer! Computers are a tool after all...
pre-empting a previous definition,
Dave Taylor
Colorado Networks - HPjoemu@tekecs.UUCP (Joe Mueller) (10/14/84)
> I hope that the standard will allow you to turn off all predefined > preprocessor variables, and give an exception list (that your program needs to > have). Things like '__LINE__' and '__FILE__' are too good to loose (in > certain applications) just because the local C compiler defines 'stack' (in a > mistaken attempt to tell you that you are executing on a stack machine, or > something...) I don't want to be forced to throw out the baby with the bath > water. > Rick Thomas Point well taken! I forgot to mention there will be a list of macros that will not be disabled by the "magic flag". __LINE__ and __FILE__ are among these. I can't remember if there are any more.
batie@omovax.UUCP (Alan Batie) (10/16/84)
A POX on 6 character variable names!!!!!!!!!! They are among the most abominable creatures ever to grace a programming language. In a related subject: What machines can't support more than 6 character variables?? Outdated software maybe, but I can't see what the underlying machine has to do with it... Yes, I know you can fit 10 chars in a CYBER word, and that makes it handy, but you can still use longer strings fairly easily. Alan Batie ...!decvax!microsoft!omovax!argent!batie
jim@ism780b.UUCP (10/17/84)
#R:decvax:-8300:ism780b:25500030:000:1134 ism780b!jim Oct 15 14:18:00 1984 >> I disagree. I've seen plenty of code which does >> >> #if foo >> or >> #if !foo >> >> and I don't think a "-Dfoo 0" should be required. > >Looks like you've seen plenty of code which is confused about the >difference between testing whether a symbol is defined and testing its >value. That's a fairly fundamental confusion, and it's easily remedied by >using ifdef/ifndef. I don't see why poor usage becomes an argument in the >standardization process. (Well, in reality I do; I wish I didn't:-) Look, poor usage is a matter of opinion. Please show me in print any usage recommendation that prefers #ifdef foo over #if foo. Personally, I consider #ifdef to be an obsolete precursor to #if. And I think the default value of "1" rather than "" when -Dfoo is given lends support to that interpretation. Given a choice between #if machine1 || machine2 || machine3 and #if defined(machine1) || defined(machine2) || defined(machine3) I prefer the former (and note that the latter was neither documented nor worked properly (try defined(STANDALONE)) until System V). -- Jim Balter, INTERACTIVE Systems (ima!jim)
henry@utzoo.UUCP (Henry Spencer) (10/22/84)
> In a related subject: What machines can't support more than 6 character > variables?? Outdated software maybe, but I can't see what the underlying > machine has to do with it... The underlying hardware (assuming it's halfway sane) is not really involved. But as far as most compiler writers are concerned, the operating system and its loader/linker might as well be part of the hardware. I.e., they are "givens" over which he has no power. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
decot@hpdsa.UUCP (decot) (10/27/84)
A solution to this problem is suggested by the comment style of Ada, which
is that portions of lines beginning with '--' are ignored. Since
this would be rather unacceptable in C, and we want the preprocessor to
handle it, the rule that leaps to mind is:
Lines or portions of lines beginning with '##' are ignored, except
within single or double quotes, or within the /* other kind of */ comment.
This rule applies even if the remainder of the line contains '/*'.
Voila! No problems with nesting, and it's always immediately obvious whether
a line is commented out, if you use consistently use only ## in new programs.
This also has the advantage that all existing correct sources would remain
correct, which is not true under comment nesting.
Dave Decot hpda!decotdavid@ukma.UUCP (David Herron) (11/07/84)
> A solution to this problem is suggested by the comment style of Ada, which > is that portions of lines beginning with '--' are ignored. Since > this would be rather unacceptable in C, and we want the preprocessor to > handle it, the rule that leaps to mind is: > > Lines or portions of lines beginning with '##' are ignored, except > within single or double quotes, or within the /* other kind of */ comment. > This rule applies even if the remainder of the line contains '/*'. > The comment style is the only thing out of Ada I like. I would go for that kind of comment style in C too. The /* other kind of */ comment is d*mn inconvenient sometimes too.
wildbill@ucbvax.ARPA (William J. Laubenheimer) (11/14/84)
> Lines or portions of lines beginning with '##' are ignored, except > within single or double quotes, or within the /* other kind of */ comment. > This rule applies even if the remainder of the line contains '/*'. > Voila! No problems with nesting, and it's always immediately obvious whether > a line is commented out, if you use consistently use only ## in new programs. > This also has the advantage that all existing correct sources would remain > correct, which is not true under comment nesting. > Dave Decot hpda!decot I realize this is a few weeks old (I've been getting behind in the news), and may have been answered already, BUT... Obviously you've never heard of EQUEL (that's okay; those of us who have spend too much time wishing we hadn't ... but that's another story). Bill Laubenheimer ----------------------------------------UC-Berkeley Computer Science ...Killjoy went that-a-way---> ucbvax!wildbill
lee@kcl-cs.UUCP (Lee McLoughlin) (11/15/84)
In article <271@ukma.UUCP> david@ukma.UUCP (David Herron) writes: >> A solution to this problem is suggested by the comment style of Ada, which >> is that portions of lines beginning with '--' are ignored. Since >> this would be rather unacceptable in C, and we want the preprocessor to >> handle it, the rule that leaps to mind is: >> >> Lines or portions of lines beginning with '##' are ignored, except >> within single or double quotes, or within the /* other kind of */ comment. >> This rule applies even if the remainder of the line contains '/*'. >> > >The comment style is the only thing out of Ada I like. I would >go for that kind of comment style in C too. The /* other kind of */ >comment is d*mn inconvenient sometimes too. I too would like to see a comment style similiar to ada's '--' however a brief warning I've seen at least one preprocessor for C (I think it was the Equel preprocessor in the Ingres system) which used '##'. But then again just about anything chosen runs the risk of clashing with an existing pre-processor. -- UKUUCP SUPPORT Lee McLoughlin <UK>!ukc!lmcl kcl-cs!lee "What you once thought was only a nightmare is now a reality!"
sambo@ukma.UUCP (Samuel A. Figueroa) (11/21/84)
Perhaps instead of using '##' to indicate that the rest of the line is a comment (since, as someone pointed out, this might conflict with at least one preprocessor), '//' could be used. The preprocessor already recognizes '/*', so adding recognition of '//' might not be too unreasonable.
ian@ic-cs.UUCP (Ian W. Moor) (12/02/84)
[it went thataway] >From: sambo@ukma.UUCP (Samuel A. Figueroa) > >Perhaps instead of using '##' to indicate that the rest of the line is a >comment (since, as someone pointed out, this might conflict with at least >one preprocessor), '//' could be used. The preprocessor already recognizes >'/*', so adding recognition of '//' might not be too unreasonable. Wait a minute ! What other wondeful language (?) uses /* and // ? All we need now is DD and EXEC statements :-) -- Ian W. Moor {mcvax,vax135}!ukc!west44!ic-cs!im Dept of Computing Imperial College "The squire on a hippopotamus is equal to 180 Queen's Gate the son of the other two squires" London SW7 2BZ