compiler bug / strange language feature

[john]

Hello world:

Gcc 4.4.3 generates a compiler error if I try to define a variable or
function called for.

However, it seems to me that because of the special syntax of the for
keyword (parentheses with two semicolons), it is always possible to
distinguish unambiguously between for being used as a keyword and for
being used as a variable or function name.

So why is it disallowed by Gcc? Is it a compiler bug or was this an
oversight when the C language was created?

Cheers
John

 

[Ike Naar]

Gcc 4.4.3 generates a compiler error if I try to define a variable or
function called for.
However, it seems to me that because of the special syntax of the for
keyword (parentheses with two semicolons), it is always possible to
distinguish unambiguously between for being used as a keyword and for
being used as a variable or function name.

It can be ambiguous:

#define for(x) /* whatever */

for(;

Is this a for statement, or an invocation of the ``for'' macro with
argument ``;;'' ?

 

[Willem]

john wrote:
) However, it seems to me that because of the special syntax of the for
) keyword (parentheses with two semicolons), it is always possible to
) distinguish unambiguously between for being used as a keyword and for
) being used as a variable or function name.

Only if you make it a non-LALR(1) grammar.
You see, when parsing C, the parser only has to look ahead 1 token
to be able to know what it is it's seeing.

) So why is it disallowed by Gcc? Is it a compiler bug or was this an
) oversight when the C language was created?

Neither. The fault lies with you.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Seebs]

However, it seems to me that because of the special syntax of the for
keyword (parentheses with two semicolons), it is always possible to
distinguish unambiguously between for being used as a keyword and for
being used as a variable or function name.

It is.

So why is it disallowed by Gcc?

Because the language spec doesn't allow it.

Is it a compiler bug or was this an
oversight when the C language was created?

Neither.

C calls certain tokens keywords, and it doesn't care whether it's "obvious"
in context that they can't have a particular special meaning; they're keywords
anyway.

This makes more sense if you look at how the lexer and parser usually work.
It's much simpler if the lexer can simply observe that "for" is a keyword
and hand back the token magic indicating that keyword, rather than the parser
having to check the names of things which might be either variables or
keywords.

Note also that the language is usually very careful never to require more
than one token of lookahead to figure out what something is. If you could
name a function "for", then the sequence "for" "(" would be ambiguous,
and indeed, you could need to parse a fairly complicated expression before
reaching the first semicolon.

Last but not least: Defining variables with the same names as keywords
is STUPID.

So, it's not a bug, nor is it an oversight.

-s

 

[John Bode]

[snip]

So, it's not a bug, nor is it an oversight.

Well, it *is* a bug, just not on the compiler's part.

 

[Eric Sosman]

Hello world:

Gcc 4.4.3 generates a compiler error if I try to define a variable or
function called for.

However, it seems to me that because of the special syntax of the for
keyword (parentheses with two semicolons), it is always possible to
distinguish unambiguously between for being used as a keyword and for
being used as a variable or function name.

So why is it disallowed by Gcc? Is it a compiler bug or was this an
oversight when the C language was created?

It's a "keyword," and can only be used as such; that's
how the language is defined, and gcc is right to complain.

Why have keywords? It makes the language easier to read
(by people and by compilers) when its "parts of speech" can
be identified early and with certainty. When you come across
a `for', you know right away that you're dealing with a `for'
statement; you don't need to suspend judgement until you've
scanned forward for what might be a considerable distance to
see whether there's a semicolon in a tell-tale place. You
don't need hypothesize about multiple possible parses, hold
them all in your mind, and await developments that will rule
out all but one: It's a `for' statement, `for' sure, and you
can get on with the business of figuring out what it does
without uncertainty about what it is.

Keywords are not a necessary feature of programming
languages, and some languages manage without them -- but C
is not one of those languages.

 

[Keith Thompson]

[snip]

So, it's not a bug, nor is it an oversight.

Well, it *is* a bug, just not on the compiler's part.

The "bug" in question is the inability to declare a variable named
"for" because "for" is a keyword.

This is certainly not what I'd call a bug. It's a deliberate feature
of the language, one that makes life easier for compiler implementers
and, I would argue, for programmers.

The alternative would be to allow keywords to be used as identifiers,
but reject the cases where this could create an ambiguity. Programmers
would have to know what those cases are, so they can understand why,
for example, they can use "for" as an identifier but not "break".

Or you could have a special syntax for keywords that distinguishes
them from identifiers, but IMHO that would be too verbose.

 

[Ben Pfaff]

Gcc 4.4.3 generates a compiler error if I try to define a variable or
function called for.

However, it seems to me that because of the special syntax of the for
keyword (parentheses with two semicolons), it is always possible to
distinguish unambiguously between for being used as a keyword and for
being used as a variable or function name.

So why is it disallowed by Gcc? Is it a compiler bug or was this an
oversight when the C language was created?

No, neither one. It simplifies language implementation if the
compiler doesn't have to think so hard to figure out whether a
word is a keyword or an identifier. The C language designers
presumably appreciated that, so the C language disallows use of
keywords as identifiers.

 

[Ben Bacarisse]

It was an oversight. You should of course be able to write:

for (for;for;for); /* for statement */
for (for,for,for); /* function call */

as well as:

if = while + for*int(goto);

if you really want.

I have a feeling you are not serious, but if you are, consider syntax
aware editors. I don't really want an editor to have to parse the kind
of grammar you are (implicitly) suggesting. There are lots of
advantages to having a simple syntax and rather few to having a
variable called 'if'.

 

[Ben Bacarisse]

It can be ambiguous:

#define for(x) /* whatever */

for(;

Is this a for statement, or an invocation of the ``for'' macro with
argument ``;;'' ?

I don't think allowing a function with the name 'for' has any effect
here. With that define, 'for(;' is unambiguously a macro
invocation regardless of whether there is function with that name
or not.

 

[Keith Thompson]

[snip]

So, it's not a bug, nor is it an oversight.

Well, it *is* a bug, just not on the compiler's part.

The "bug" in question is the inability to declare a variable named
"for" because "for" is a keyword.

I believe what John is saying is that there's a bug in the program, not in
the compiler or the language definition...

Ok, that makes sense.

 

[Gene]

No, neither one.  It simplifies language implementation if the
compiler doesn't have to think so hard to figure out whether a
word is a keyword or an identifier.  The C language designers
presumably appreciated that, so the C language disallows use of
keywords as identifiers.

Very true. The early computer science community's notion that anything
technically possible ought to be allowed in a language resulted in PL/
1, which was so complicated to implement that, apparently, there never
was a compiler for the complete language, only subsets. PL/1 did not
reserve its keywords from use as identifiers. This is a syntactically
correct PL/1 statement:

IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;

Reserving keywords allows parsers to better determine what the
programmer meant when provided with a syntactically incorrect program.

Simplicity is also good for people. Programs are generally read much
more often than written. Needing to figure out if a particular use of
FOR is a keyword or identifier is a waste of the reader's time. Tiny,
perhaps, but still a waste. This is an argument (and a reasonable
one) against other langauge features like operator and function
overloading and macro facilities. They require every reader to figure
out the "custom" language in use before reading the code.

 

[Tim Rentsch]

Hello world:

Gcc 4.4.3 generates a compiler error if I try to define a variable or
function called for.

However, it seems to me that because of the special syntax of the for
keyword (parentheses with two semicolons), it is always possible to
distinguish unambiguously between for being used as a keyword and for
being used as a variable or function name.

So why is it disallowed by Gcc? Is it a compiler bug or was this an
oversight when the C language was created?

It's a "keyword," and can only be used as such; that's
how the language is defined, and gcc is right to complain.
[snip elaboration]

More properly, it's a reserved word. There are languages
that have keywords that are not reserved words.

 

[Eric Sosman]

[... concerning `for' ...]
It's a "keyword," and can only be used as such; that's
how the language is defined, and gcc is right to complain.
[snip elaboration]

More properly, it's a reserved word. There are languages
that have keywords that are not reserved words.

More properly, it's a keyword. 6.4.1p1.

(You made me look, though.)

 

[Tim Rentsch]

[... concerning `for' ...]
It's a "keyword," and can only be used as such; that's
how the language is defined, and gcc is right to complain.
[snip elaboration]

More properly, it's a reserved word. There are languages
that have keywords that are not reserved words.

More properly, it's a keyword. 6.4.1p1.

(You made me look, though.)

6.4.1p2:

The above tokens (case sensitive) are _reserved_ [emphasis added]
(in translation phases 7 and 8) for use as keywords, and shall not
be used otherwise.

My comment was about usage in English, not about terminology
in the C Standard. The key property you are trying to point
out is that these words are reserved and may not be used as
ordinary identifiers. It's true that 'for' is a keyword,
but what's important is that the token 'for' is _reserved_
(in phases 7 and 8) to be just a keyword and nothing else.

Sorry if my comment was confusing; I was just trying to
improve the usage, not correct your facts.

 

[Tim Rentsch]

It's a "keyword," and can only be used as such; that's
how the language is defined, and gcc is right to complain.
[snip elaboration]

More properly, it's a reserved word. There are languages
that have keywords that are not reserved words.

You won't find the phrase "reserved words" in the C standard.

Under "reserved identifiers"
in the index you will find: 6.4.1, 7.1.3
which are:
6.4.1 Keywords
7.1.3 Reserved identifiers

N869, which is a draft but not a C standard,
does have the phrase "reserved words" in the index
and it shows "reserved words, 6.4.1"
which again is keywords.

Again, my comment was about usage in English, not
about terminology in the C Standard. But see also
6.4.1p2; the word "reserved" is used to signify
the important property.

 

[Eric Sosman]

[... concerning `for' ...]
It's a "keyword," and can only be used as such; that's
how the language is defined, and gcc is right to complain.
[snip elaboration]

More properly, it's a reserved word. There are languages
that have keywords that are not reserved words.

More properly, it's a keyword. 6.4.1p1.

(You made me look, though.)

6.4.1p2:

The above tokens (case sensitive) are _reserved_ [emphasis added]
(in translation phases 7 and 8) for use as keywords, and shall not
be used otherwise.

My comment was about usage in English, not about terminology
in the C Standard. [...]

My comment was about terminology in the C Standard, and
why that terminology justifies a C compiler's rejection of
an attempt to use `for' as an identifier. The O.P. asked "Why
is it disallowed by gcc?" and the reason doesn't come from
English usage, but from the language of the Standard.

 

[Tim Rentsch]

On 3/27/2010 8:02 AM, Tim Rentsch wrote:
[... concerning `for' ...]
It's a "keyword," and can only be used as such; that's
how the language is defined, and gcc is right to complain.
[snip elaboration]

More properly, it's a reserved word. There are languages
that have keywords that are not reserved words.

More properly, it's a keyword. 6.4.1p1.

(You made me look, though.)

6.4.1p2:

The above tokens (case sensitive) are _reserved_ [emphasis added]
(in translation phases 7 and 8) for use as keywords, and shall not
be used otherwise.

My comment was about usage in English, not about terminology
in the C Standard. [...]

My comment was about terminology in the C Standard, and
why that terminology justifies a C compiler's rejection of
an attempt to use `for' as an identifier. The O.P. asked "Why
is it disallowed by gcc?" and the reason doesn't come from
English usage, but from the language of the Standard.

Yes, and the salient fact, as identified by text in the
Standard, is that the token 'for' is reserved which
prevents its use as an ordinary identifier. It isn't because
'for' is a keyword, but because such tokens are reserved
that they cannot be used other than as keywords. Telling
him it's a keyword doesn't say anything about why it can't
be used; conversely, saying that the token 'for' is
reserved, by the C Standard, to be used as a keyword
and not as an ordinary identifier, does say why it can't
be used, as well as identifying the relevant C terminology.

Cf. Judging Books by Their Covers, in "Surely You're
Joking, Mr. Feynman" ("Energy makes it go")