semantic question

[mdh]

Perhaps slightly OT, but related to Declarator form.

From A8.5, the declarators have the syntax;

declarator:

ptr (opt) direct-declarator.


At the bottom of the page, it says, amongst other things
"...structure....resembles...indirection, function......"


For those steeped in the history of C, what is the origin of the
"direct" in direct-declarator. Is there an "indirect-
declarator"......as in the pointer ( being the indirection
operator?).

Googling...I know the term carries some negative connotations...gives
one ref to "indirect-declarator" which possibly supports my
suspicion...but nothing definitive.

Anyway...apologise in advance if this question is way OT.

 

[mdh]

     First, I'm unfamiliar with this "A8.5" you mention.

It's on p 215 of K&R2....the Reference Manual. But, as I see from
the opening paragraph on p191, "the (Reference) manual is an
interpretation of the proposed standard, not the Standard
itself...." So, your following statement is well taken.

 >What

you've shown looks like an inaccurate approximation of part of
the grammar shown in the Standard's section 6.7.5 paragraph 1,

But as to the origin of the term "direct-declarator," it's
most probably just a made-up name for a non-terminal symbol
that is part of but not the entirety of a "declarator."  There
is no "indirect-declarator" in the Standard's grammar for C.

Well, the reason for the confusion is this.

On P123, in explaining complex declarators, this example is used.


(*pfa)[]()

To quote K&R.

pfa will be identified as a name and thus a direct-dcl.
Then pfa[] is also a direct-dcl.
Then *pfa[] is a recognized as a dcl, so (*pfa[]) is a direct-dcl.
( I think, (*pfa[]) meets the criteria of a direct-dcl simply from the
definition provided earlier...btw I think there is a typo here...but I
left it in as I have never seen any other in K&R).
However, this next sentence has me flummoxed.
Then (*pfa[])() is a direct-dcl and thus a dcl.

There is a nice picture of a parse tree on that page that I am unable
to replicate, but even that does not adequately ( to me at least )
explain that last sentence.

Any, Eric, thanks for your input.

 

[Ben Bacarisse]

Well, the reason for the confusion is this.

On P123, in explaining complex declarators, this example is used.

(*pfa)[]()

Before there is even more confusion, I think you mean (*pfa[])(). Is
this the type of which you speak below?

To quote K&R.

pfa will be identified as a name and thus a direct-dcl.
Then pfa[] is also a direct-dcl.
Then *pfa[] is a recognized as a dcl, so (*pfa[]) is a direct-dcl.
( I think, (*pfa[]) meets the criteria of a direct-dcl simply from the
definition provided earlier...btw I think there is a typo here...but I
left it in as I have never seen any other in K&R).

What do you think is the typo? Apart from the overall string we are
parsing, it seems correct so far.

However, this next sentence has me flummoxed.
Then (*pfa[])() is a direct-dcl and thus a dcl.

Why? You seem to accept that (*pfa[]) is a direct-delarator and one
of the options for direct-delarator is:

direct-delarator ( identifier-list-opt )

(using -opt to mean optional) so (*pfa[])() is one too. A declarator
may simply be a direct-delarator without any pointer part so this is
also a declarator.

There is a nice picture of a parse tree on that page that I am unable
to replicate, but even that does not adequately ( to me at least )
explain that last sentence.

Maybe you miss the rule:

declarator:
pointer-opt direct-declarator

 

[Keith Thompson]

Perhaps slightly OT, but related to Declarator form.

From A8.5, the declarators have the syntax;

declarator:

ptr (opt) direct-declarator.


At the bottom of the page, it says, amongst other things
"...structure....resembles...indirection, function......"


For those steeped in the history of C, what is the origin of the
"direct" in direct-declarator. Is there an "indirect-
declarator"......as in the pointer ( being the indirection
operator?).
[...]

Anyway...apologise in advance if this question is way OT.

Just out of curiosity, why would you think this would be off-topic?
It's a question about C.

 

[Antoninus Twink]

Just out of curiosity, why would you think this would be off-topic?

Long experience that you and your ilk consider most things "off-topic"?

 

[mdh]

this example is used.

(*pfa)[]()

Before there is even more confusion, I think you mean (*pfa[])().  Is
this the type of which you speak below?

Yes...that **is** my typo. The typo I was referring to is the
sentence,


"Then *pfa[] is a recognized as a dcl, so (*pfa[]) is a direct-dcl."

However, this next sentence has me flummoxed.
Then (*pfa[])() is a direct-dcl and thus a dcl.

Why?  You seem to accept that (*pfa[]) is a direct-delarator and one
of the options for direct-delarator is:

  direct-delarator ( identifier-list-opt )

(using -opt to mean optional) so (*pfa[])() is one too.  A declarator
may simply be a direct-delarator without any pointer part so this is
also a declarator.

So, this is nothing more than looking at the syntax and fitting it
into the grammar for the language, here the standard? I guess I was
looking for too much logic here. I think you are correctly saying, in
effect, this is a direct-declarator or a declarator because that is
the way it is defined, whereas I was trying to find the logic of
**why** C names it so...trying to see why "*s" would not be called a
direct-declarator or perhap "indirect declarator". Eric offered his
thoughts when he said "But as to the origin of the term "direct-
declarator," it's most probably just a made-up name for a non-terminal
symbol that is part of but not the entirety of a "declarator."

 

[mdh]

Just out of curiosity, why would you think this would be off-topic?
It's a question about C.

So many questions to clc concentrate on actual code with code snippets
supplied. My questions are often as to the reason **why** things are
so, and every now and again I worry that those questions will be
perceived as nonsense or petty.

 

[Ben Bacarisse]

this example is used.

(*pfa)[]()

Before there is even more confusion, I think you mean (*pfa[])().  Is
this the type of which you speak below?

Yes...that **is** my typo. The typo I was referring to is the
sentence,


"Then *pfa[] is a recognized as a dcl, so (*pfa[]) is a direct-dcl."

Do you now see how this is correct or is it still bothering you? If
it is still a problem, look at the syntax for direct-declarator and
see if any match (*pfa[]) given that you know *pfa[] is a declarator.

However, this next sentence has me flummoxed.
Then (*pfa[])() is a direct-dcl and thus a dcl.

Why?  You seem to accept that (*pfa[]) is a direct-delarator and one
of the options for direct-delarator is:

  direct-delarator ( identifier-list-opt )

(using -opt to mean optional) so (*pfa[])() is one too.  A declarator
may simply be a direct-delarator without any pointer part so this is
also a declarator.

So, this is nothing more than looking at the syntax and fitting it
into the grammar for the language, here the standard?

Yup. That is what the compiler does, and if you need to name that parts
of your program, it is what you need to do, but most people don't care
about these details.

I guess I was
looking for too much logic here. I think you are correctly saying, in
effect, this is a direct-declarator or a declarator because that is
the way it is defined, whereas I was trying to find the logic of
**why** C names it so...trying to see why "*s" would not be called a
direct-declarator or perhap "indirect declarator". Eric offered his
thoughts when he said "But as to the origin of the term "direct-
declarator," it's most probably just a made-up name for a non-terminal
symbol that is part of but not the entirety of a "declarator."

It is possible that the name was chosen because that part of a
declarator that has no *s, but I certainly don't know that for a fact.
If you have every written a grammar for a language you will know that
you often need names of all sorts of "bits" that don't have an obvious
one. I get that feeling with declaration, declaration-specifiers,
init-declarator-list, init-declarator, declarator,
struct-declaration-list, struct-declaration, direct-declarator,
abstract-declarator, direct-abstract-declarator... I bet the authors
were running out of good descriptive names by this point.

 

[mdh]

.
If you have every written a grammar for a language you will know that
you often need names of all sorts of "bits" that don't have an obvious
one.

I think you have hit the nail on the head for me. When, as a newbie,
that tries to understand everything, sees this, I try to make "sense"
of it. Whereas someone like you, who has probably written , I imagine,
languages ( ? including c) sees this just as part of a chain of
actually getting the compiler to "work" and is thus far more
understanding of all that goes into making this happen....(including
naming conventions).

Thanks again for taking the time to answer. I **think** I am happy
now!!!!

 

[Keith Thompson]

So many questions to clc concentrate on actual code with code snippets
supplied. My questions are often as to the reason **why** things are
so, and every now and again I worry that those questions will be
perceived as nonsense or petty.

Don't worry about it. Questions about the history of the language and
why it is the way it is are quite topical.

 

[Kenny McCormack]

Don't worry about it. Questions about the history of the language and
why it is the way it is are quite topical.

Wrong. There is no mention in any of the C standards documents of words
like "why" or "history".

 

[Harald van Dijk]

Wrong. There is no mention in any of the C standards documents of words
like "why" or "history".

Actually, there is mention of it (but not more than that) in the foreword:

"International Standard ISO/IEC 9899 was prepared by Joint Technical
Committee ISO/IEC JTC 1, /Information technology/, Subcommittee SC 22,
/Programming languages, their environments and system software
interfaces/. The Working Group responsible for this standard (WG 14)
maintains a site on the World Wide Web at
http://www.dkuug.dk/JTC1/SC22/WG14/ containing additional information
relevant to this standard such as a Rationale for many of the decisions
made during its preparation and a log of Defect Reports and Responses."

Not that this really matters, of course. I'm sure Keith would have posted
that C history is topical even if the foreword didn't mention this, and
you would then still be one of the few to disagree.

 

[Kenny McCormack]

Wrong. There is no mention in any of the C standards documents of words
like "why" or "history".

Actually, there is mention of it (but not more than that) in the foreword:

"International Standard ISO/IEC 9899 was prepared by Joint Technical
Committee ISO/IEC JTC 1, /Information technology/, Subcommittee SC 22,
/Programming languages, their environments and system software
interfaces/. The Working Group responsible for this standard (WG 14)
maintains a site on the World Wide Web at
http://www.dkuug.dk/JTC1/SC22/WG14/ containing additional information
relevant to this standard such as a Rationale for many of the decisions
made during its preparation and a log of Defect Reports and Responses."[/QUOTE]

I don't see either of the words "why" or "history" in the paragraph you
quoted.

Yes, I know this sounds picky, but this is the dogma of this group.
We are very, very, literal around here, as you well know.

I'm just trying to fit in. Really, I am.

Not that this really matters, of course. I'm sure Keith would have posted
that C history is topical even if the foreword didn't mention this, and
you would then still be one of the few to disagree.

Of course. On all counts.

 

[Keith Thompson]

Actually, there is mention of it (but not more than that) in the foreword:

[snip]

Please don't feed the troll. Remember, if you tell a troll he's
wrong, he wins. If you ignore him, he loses.

 

[Richard]

Actually, there is mention of it (but not more than that) in the foreword:

[snip]

Please don't feed the troll. Remember, if you tell a troll he's
wrong, he wins. If you ignore him, he loses.

The development of C and the reasons for things being like they are are
totally topical. This group is called comp.lang.c and is for the
discussion of the C Programming Language.

 

[santosh]

On Sat, 09 Aug 2008 10:33:53 +0000, Kenny McCormack wrote:
Don't worry about it. Questions about the history of the language
and why it is the way it is are quite topical.

Wrong. There is no mention in any of the C standards documents of
words like "why" or "history".

Actually, there is mention of it (but not more than that) in the
foreword:

[snip]

Please don't feed the troll. Remember, if you tell a troll he's
wrong, he wins. If you ignore him, he loses.

The development of C and the reasons for things being like they are
are totally topical. This group is called comp.lang.c and is for the
discussion of the C Programming Language.

Um, that's what Keith said too, and what Kenny refuted, rather
childishly.

 

[Harald van Dijk]

Actually, there is mention of it (but not more than that) in the
foreword:

[snip]

Please don't feed the troll. Remember, if you tell a troll he's wrong,
he wins. If you ignore him, he loses.

I responded to Kenny because I considered the response appropriate for the
group and somewhat interesting, and ignored his follow-up for similar
reasons. I'd say if you let trolls decide when and what you can and cannot
post, they win, both if you post something you otherwise wouldn't, and if
don't post something you otherwise would. Or, in other words, I'd rather
not change my posting habits just because of Kenny.

 

[Antoninus Twink]

Um, that's what Keith said too, and what Kenny refuted, rather
childishly.

We all know that Kenny was being satirical, and that Keith believes this
group is for the discussion of ISO C, not C.

 

[Kenny McCormack]

We all know that Kenny was being satirical, and that Keith believes this
group is for the discussion of ISO C, not C.

Quite seriously, the point I was making was that the regs feel entirely
justified in using the standard to club the newbies. Anytime the newbie
mentions something not explicitly mentioned in the standard (the classic
example of this is that which I have come to refer to as "the S-word"),
the regs all go on a whirlwind of viciously pointing out that the
standard doesn't mention that thing and that therefore they (the newbies)
are less than pond scum for mentioning it here in their sacred group.

Yet, of course, the regs are free to discuss whatever they want
(including a long thread on gcc options), with nary a care. Obviously,
for them, the fact that something isn't mentioned in their holy books is
no impediment.