C# 2.0 language grammar

[Guest]

Hello,

I have a question about the correctness of the language grammar for the C#
2.0 specification. I am working with the grammar specified in the June 2005
ECMA-334 standard.

Basically, a using-namespace-directive is defined as follows:

using-namespace-directive:
using namespace-name ;

namespace-name:
namespace-or-type-name

namespace-or-type-name:
identifier type-argument-list (opt)
...

type-argument-list:
< type >

Note that the above productions allow this statement to be legal (even if it
doesn't
semantically make sense):

using System<int>;

Obviously, this doesn't make semantic sense in this context. I'm wondering
why
a new production was not introduced specifically for this context as opposed
to using the semantic information provided by the directive itself to not
allow the type-argument-list (optional of course means it could be there).
Any thoughts?

Thanks!

 

[Kevin Spencer]

From Sectin 10.8:

"Following resolution as described below, the namespace-or-type-name of a
namespace-name shall refer to a
namespace, or otherwise a compile-time error occurs. Type arguments
(§25.5.1) shall not be present in a
namespace-name (only types can have type arguments).
A type-name is a namespace-or-type-name that refers to a type. Following
resolution as described below, the
namespace-or-type-name of a type-name shall refer to a type, or otherwise a
compile-time error occurs."

What exactly is the purpose of your query? Wouldn't you expect that enough
highly-qualified people have reviiewed this spec before you looked it over?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Guest]

Of course I expect that enough highly-qualified people have reviewed the
spec, that is not the point. My question was simply why a namespace-name
referred to a namespace-or-type-name rather than simply doing:

namespace-name:
identifier
qualified-alias-member
namespace-name . identifier

In the grammar as presented in the spec, the production carries semantic
information that is present elsewhere in the document as opposed to being
self-describing. It was more a question of academic nature and curiosity
rather than serving any practical use.

 

[Brian Gideon]

Magius,

I apologize in advance for hijacking your thread, but my question is
slightly related. I noticed that the behavior of the using directive
is different depending on where it is placed in version 1.1. I posted
this several months ago, but I never got a satisfactory response. Why
is the behavior different? Where is it mentioned in the specification?
I didn't see any mention of it section 16.3 of the ECMA specification.
Does 2.0 behave this way? For example:

// The following line imports namespace B types (Bar1 & Bar2).
using B;
namespace A.C.D
{
// The following line imports namespace A.B types (Foo1 & Foo2).
using B;
}

namespace A.B
{
public class Foo1 { }
public class Foo2 { }
}

namespace B
{
public class Bar1 { }
public class Bar2 { }
}

Brian

 

[Guest]

Hi Brian,

No problem with the hijack.

I think that what you refer to is implied in Section 10.7 Scopes of the ECMA
document I am referring to. Specifically:

"The scope of a namespace member declared by a namespace-member-declaration
within a namespace-declaration whose fully qualified name is N, is the
namespace-body of every namespace-declaration whose fully qualified name is N
or starts with N, followed by a period."

In this case, I think that since A.B is a namespace-member-declaration in
the A scope, it's valid scope is A and the namespace-body of every
namespace-declaration whose fully qualified name starts with A. (A.C.D).
Therefore, the compiler interprets the using B in the scope of A.C.D where
A.B is valid and imports the types in the namespace A.B. I think the
language used in that paragraph is poor (if I'm interpreting it right), but I
think that's what it means

 

[Jon Skeet [C# MVP]]

What exactly is the purpose of your query? Wouldn't you expect that enough
highly-qualified people have reviiewed this spec before you looked it over?

Just because good people have already looked over a spec doesn't mean
there aren't mistakes in it - I found a few in the CLI spec and (IIRC)
the C# 1 spec too...

 

[Kevin Spencer]

Well, it was quite well spelled-out in this case, and made perfect sense.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Jon Skeet [C# MVP]]

Well, it was quite well spelled-out in this case, and made perfect sense.

But the question still made sense, and as far as I can tell hasn't
really been answered - why was the current production chosen instead of
the one suggested in the second post?

 

[Brian Gideon]

Magius,

It took me a little while to think that through, but I think you might
be right. The meaning of that sentence wasn't immediately clear to me
at first. I'll have to mull that over a while longer.

Brian

 

[Kevin Spencer]

But the question still made sense, and as far as I can tell hasn't

really been answered - why was the current production chosen instead of
the one suggested in the second post?

When faced with 2 choices, both equally correct, an arbitrary decision is in
order. Indecision is always a show-stopper. What might seem intuitive to one
person (or one culture) is gibberish to another. So, in this case, I would
have to suppose that an arbitrary decision was made, and that, under the
circumstances, either way would have been fine. I could be wrong. There may
be an underlying uniform methodolgy or set of Best Practices at work, for
all I know. I do know that Microsoft is very good at sticking to one
methodology in order to make things simpler for the user of the technology.
And that makes sense to me.

For example, one might consider the issue of HotKeys. I can remember back in
the day, before windowed operating systems became all the rage, and there
were no standards regarding such things. One often had to keep a "cheat
sheet" of HotKeys for each program one ran, and refer to it often. Microsoft
early on decided on a set of HotKeys that they implemented uniformly across
all of their software. It included the SHIFT<KEY> combinations for things
like selecting, copying, cutting, etc. Of course, they later realized that
thisstandard was not as extensible as would be needed, and implemented the
current Microsoft CTRL<KEY> HotKeys, which are now the Microsoft standard.
Now, of course there were other considerations involved, but why, for
example, was CTRL<Y> chosen for "undo" instead of, say CTRL<U>? I don't
know. Perhaps there was some study in ergonomics involved; who knows? In any
case, a decision was made, and production moved forward.

As a side note, it is interesting to me to note that the older HotKey
combinations are also still supported in virtually all Microsoft software.
Now, that's user-friendliness for you!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Guest]

While I agree that it probably boiled down to an arbitrary decision, I must
question the logic as to why it was arbitrary at all. If you examine the
language grammar, you see that the only time a namespace-name or
namespace-type-name production is used is in the context of a using-directive
or using-alias-directive. Now, if this is the only time that these
particular productions are used, and according to the grammar it is, then I
question the logic in constructing the namespace-name and namespace-type-name
productions in that manner. Specifically, it is now necessary to rely on the
semantic information presented in Section 10 of the ECMA document in order to
fully grasp the grammar in terms of these using directives. A much better
solution, in my opinion, is to state this explicitly in the grammar itself.
I could see the logic if the namespace-name and namespace-type-name
productions were used elsewhere in the grammar - perhaps there would be a
need for some condensing of information to not have the grammar explode, but
in this case it makes little sense to simply use the same rules for
namespace-or-type-name and type-name and have implementers of lexical tools
rely on the semantic information contained in the document itself rather than
being explicitly clear in the grammar itself.

My concern is that with the explosion of C# language features (take a look
at the 3.0 specification), the language grammar becomes unusable. In my
opinion, I should have to rely as little as possible on semantic information
when I perform a "pure parse" of a C# document. There are times when
semantic information is needed, i.e. private is a legal class modifier if I
am within the scope of another class and not directly in the namespace scope.
However, it makes little sense to rely on semantic information in the case I
have presented above. Continuing down this road leads to the grammar
becoming useless and with the explosion of language elements I think this is
something the language implementers should be wary of.
--
Magius

But the question still made sense, and as far as I can tell hasn't
really been answered - why was the current production chosen instead of
the one suggested in the second post?

When faced with 2 choices, both equally correct, an arbitrary decision is in
order. Indecision is always a show-stopper. What might seem intuitive to one
person (or one culture) is gibberish to another. So, in this case, I would
have to suppose that an arbitrary decision was made, and that, under the
circumstances, either way would have been fine. I could be wrong. There may
be an underlying uniform methodolgy or set of Best Practices at work, for
all I know. I do know that Microsoft is very good at sticking to one
methodology in order to make things simpler for the user of the technology.
And that makes sense to me.

For example, one might consider the issue of HotKeys. I can remember back in
the day, before windowed operating systems became all the rage, and there
were no standards regarding such things. One often had to keep a "cheat
sheet" of HotKeys for each program one ran, and refer to it often. Microsoft
early on decided on a set of HotKeys that they implemented uniformly across
all of their software. It included the SHIFT<KEY> combinations for things
like selecting, copying, cutting, etc. Of course, they later realized that
thisstandard was not as extensible as would be needed, and implemented the
current Microsoft CTRL<KEY> HotKeys, which are now the Microsoft standard.
Now, of course there were other considerations involved, but why, for
example, was CTRL<Y> chosen for "undo" instead of, say CTRL<U>? I don't
know. Perhaps there was some study in ergonomics involved; who knows? In any
case, a decision was made, and production moved forward.

As a side note, it is interesting to me to note that the older HotKey
combinations are also still supported in virtually all Microsoft software.
Now, that's user-friendliness for you!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Kevin Spencer]

I can see your point.

However, the real point in this case is the usage of the using Directive. I
have in the past wished that a type could be included as a using directive,
when, for example, using a set of static methods that all exist in the same
class. The purpose of the using directive is for the convenience of the
developer (not having to retype namespaces over and over again), and for the
clarity of the code (removing redundant code). The ability to specify a type
as a namespace is a desirable one.

The problem lies in the fact that while a type is a namespace, a namespace
is not necessarily a type. This same situation has cropped up in XML as
well, necessitating the creation of rules for namespaces that are used only
for the purpose of uniquely identifying elements. The purpose of a
"typeless" namespace in C# is basically the same.

This is, of course, the reason that namespaces cannot be generic. And type
parameter lists are definitions of the type parameters which make a Generic
type strongly typed. So, one cannot pass a type parameter list to a
namespace.

Generics are one of many new featuers added to the C# language, but a very
important, if not the most important one. C# Generics are very similar to
C++ Templates, and provide the same capabilities that Templates afford to
C++, using much the same syntax. Perhaps your suggestion that the constraint
be included in the grammar is a good one, but on the other hand, the using
directive regarding namespaces is a unique case. I can't imagine (although I
can't say it isn't possible) that this situation would occur elsewhere.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

While I agree that it probably boiled down to an arbitrary decision, I
must
question the logic as to why it was arbitrary at all. If you examine the
language grammar, you see that the only time a namespace-name or
namespace-type-name production is used is in the context of a
using-directive
or using-alias-directive. Now, if this is the only time that these
particular productions are used, and according to the grammar it is, then
I
question the logic in constructing the namespace-name and
namespace-type-name
productions in that manner. Specifically, it is now necessary to rely on
the
semantic information presented in Section 10 of the ECMA document in order
to
fully grasp the grammar in terms of these using directives. A much better
solution, in my opinion, is to state this explicitly in the grammar
itself.
I could see the logic if the namespace-name and namespace-type-name
productions were used elsewhere in the grammar - perhaps there would be a
need for some condensing of information to not have the grammar explode,
but
in this case it makes little sense to simply use the same rules for
namespace-or-type-name and type-name and have implementers of lexical
tools
rely on the semantic information contained in the document itself rather
than
being explicitly clear in the grammar itself.

My concern is that with the explosion of C# language features (take a look
at the 3.0 specification), the language grammar becomes unusable. In my
opinion, I should have to rely as little as possible on semantic
information
when I perform a "pure parse" of a C# document. There are times when
semantic information is needed, i.e. private is a legal class modifier if
I
am within the scope of another class and not directly in the namespace
scope.
However, it makes little sense to rely on semantic information in the case
I
have presented above. Continuing down this road leads to the grammar
becoming useless and with the explosion of language elements I think this
is
something the language implementers should be wary of.

 

[Guest]

It would indeed be nice to have the using directive mean a static type, but I
see your reasoning why this isn't included.

I just wish that the reviewers would spend a little more time looking at the
grammar since it really defines the syntactic structure of the language.
Let's keep the syntax rules with the syntax and the semantic rules in the
document

I also noticed that they forgot to include shift-expression in Appendix C
(Grammar) but it is spelled out in the document contents. Anyway, thanks for
the discussion!

 

[Guest]

I take that last statement back, shift-expression is indeed in Appendix C,
there is just a new-line missing in the pdf document to separate it from and
additive-expression.

Sorry to mislead.

 

[Kevin Spencer]

Anyway, thanks for

the discussion!

Same here, Magius. It was an opportunity to study and learn more, which is
always a good thing!

--

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.