Re: C# 2.0 language grammar

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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]" <skeet@xxxxxxxxx> wrote in message
> news:MPG.1dba295c7587fbfa98c8fe@xxxxxxxxxxxxxxxxxxxxxxx
> > Kevin Spencer <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx> 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 - <skeet@xxxxxxxxx>
> > http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> > If replying to the group, please do not mail me too
>
>
>
.

Relevant Pages