By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,141 Members | 1,266 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,141 IT Pros & Developers. It's quick & easy.

C# 2.0 language grammar

P: n/a
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!
--
Magius
Nov 17 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
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.

"Magius" <Ma****@discussions.microsoft.com> wrote in message
news:36**********************************@microsof t.com...
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!
--
Magius

Nov 17 '05 #2

P: n/a
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.

--
Magius
"Kevin Spencer" wrote:
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.

"Magius" <Ma****@discussions.microsoft.com> wrote in message
news:36**********************************@microsof t.com...
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!
--
Magius


Nov 17 '05 #3

P: n/a
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

Magius wrote:
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!
--
Magius


Nov 17 '05 #4

P: n/a
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 :)
--
Magius
"Brian Gideon" wrote:
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

Magius wrote:
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!
--
Magius


Nov 17 '05 #5

P: n/a
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
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...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #6

P: n/a
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]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
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...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #7

P: n/a
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #8

P: n/a
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

Magius wrote:
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 :)
--
Magius


Nov 17 '05 #9

P: n/a
> 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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 17 '05 #10

P: n/a
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
"Kevin Spencer" wrote:
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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too


Nov 17 '05 #11

P: n/a
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.

"Magius" <Ma****@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com...
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
"Kevin Spencer" wrote:
> 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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
> Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
>> 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?
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too


Nov 17 '05 #12

P: n/a
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!

--
Magius
"Kevin Spencer" wrote:
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.

"Magius" <Ma****@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com...
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
"Kevin Spencer" wrote:
> 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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
> Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
>> 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?
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too


Nov 17 '05 #13

P: n/a
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.

--
Magius
"Magius" wrote:
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!

--
Magius
"Kevin Spencer" wrote:
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.

"Magius" <Ma****@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com...
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
"Kevin Spencer" wrote:

> > 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.
>
> "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> news:MP************************@msnews.microsoft.c om...
> > Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
> >> 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?
> >
> > --
> > Jon Skeet - <sk***@pobox.com>
> > http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> > If replying to the group, please do not mail me too
>
>
>


Nov 17 '05 #14

P: n/a
> 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.

"Magius" <Ma****@discussions.microsoft.com> wrote in message
news:39**********************************@microsof t.com... 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!

--
Magius
"Kevin Spencer" wrote:
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.

"Magius" <Ma****@discussions.microsoft.com> wrote in message
news:68**********************************@microsof t.com...
> 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
>
>
> "Kevin Spencer" wrote:
>
>> > 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.
>>
>> "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
>> news:MP************************@msnews.microsoft.c om...
>> > Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:
>> >> 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?
>> >
>> > --
>> > Jon Skeet - <sk***@pobox.com>
>> > http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
>> > If replying to the group, please do not mail me too
>>
>>
>>


Nov 17 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.