Replies: 22 comments
-
What benefit would this provide to the language? You can already escape reserved keywords for use as identifiers by prefixing them with As for making it easier to add new contextual keywords, I don't see how that possibly would help. The design team would still need to ensure that the no existing code would break or change semantics by adding the new keyword. |
Beta Was this translation helpful? Give feedback.
-
The advantage it would provide is that no existing code could break, that's the point I was making. By altering the language parser to eliminate reserved words it is not possible for existing code to break when new keywords are added - don't confuse keywords with reserved words. However the C# grammar may itself prevent this, I haven't checked. |
Beta Was this translation helpful? Give feedback.
-
but why. |
Beta Was this translation helpful? Give feedback.
-
sorry, you already mentioned why. |
Beta Was this translation helpful? Give feedback.
-
Why? so that the language designers can add new keywords in future releases yet guarantee that no existing source code would be illegal. |
Beta Was this translation helpful? Give feedback.
-
This may not be possible grammatically, so it may be impossible now. Unless the grammar is designed from the outset correctly, it isn't possible to easily do this. PL/I (I actually wrote a parser for this) was elegant in this respect and the grammar made it easy to support this. I think this is all due to C# being based on Java, Java being based on C++ and C++ being based on C, grammatical weaknesses in C have plagued all derivative languages. |
Beta Was this translation helpful? Give feedback.
-
Same has been done for |
Beta Was this translation helpful? Give feedback.
-
So your proposal isn't about eliminating keywords, it's about making them all contextual. That only works when the syntax of the language is designed very specifically from the beginning to support something like this. Otherwise I doubt it's possible to disambiguate parsing the semantics of the language in many cases. That's true even of contextual keywords, most of them can be "broken" by scope, like Either way, it sounds like a lot of work for very little reward. C# already allows you to escape keywords for use as identifiers, so it's not like you're prevented from using them. And it should be a relatively rare need anyway. |
Beta Was this translation helpful? Give feedback.
-
@HaloFour I disagree. it'd be great to be able to do this: public class return {
private return catch(default try) {
if finally = else(try);
finally.new = new checked();
return null;
}
} |
Beta Was this translation helpful? Give feedback.
-
Not sure if it's meant as a joke, but actually, it'll be useful when your codebase is about ASTs, e.g. Roslyn:
|
Beta Was this translation helpful? Give feedback.
-
public class @return {
private @return @catch(@default @try) {
@if @finally = @else(@try);
@finally.@new = new @checked();
return null;
}
} |
Beta Was this translation helpful? Give feedback.
-
That's the point I'm trying to make. Then there would be absolutely no difference between the compiler implementation and the code it's compling (bootstrapping). |
Beta Was this translation helpful? Give feedback.
-
@HaloFour |
Beta Was this translation helpful? Give feedback.
-
And you've just demonstrated why this is impossible. |
Beta Was this translation helpful? Give feedback.
-
@HaloFour Never a fan of character escapes.
Gotcha, null was a field (probably). |
Beta Was this translation helpful? Give feedback.
-
@HaloFour The motive is that the language designers could introduce new keywords whenever they wished and know that no existing code that compiles, would break. There's an article about this by Eric Lippert As that explains some keywords in C# are "contextual" so this is legal:
whereas this is not:
The PL/I grammar was designed from the outset be flexible allowing new keywords to be introduced with no chance whatsoever of breaking existing code (if that code already compiled). Another consequence of the grammar is that keywords can be ordered arbitrarily, if C# had this capability these would all be legal:
PL/I has no concept of "contextual" keywords, if a statement can't be parsed as a
then it's parsed as a keyword - and that will either be legal or illegal depending upon the first identifier in the statement. That's why all declarations in PL/I use the "declare" (or "dcl") keyword, C never had this (even though the designers of C had worked with PL/I on Multics, this is where C gets the /* comment */ from) and the poor C grammar has polluted many derivative languages. Anyway, this is now academic and I don't expect C# to be modified to this extent! |
Beta Was this translation helpful? Give feedback.
-
Yes, and that's very specific to that language. You can't with any reasonable amount of effort change C#'s existing grammar (or the grammar of any long-standing language for that matter) to something even remotely similar without it making billions of lines of code ambiguous. |
Beta Was this translation helpful? Give feedback.
-
@Joe4evr - I think you're right, the only way to consider this would be to invent a new .Net OO language, one which isn't concerned with the C heritage and all that implies. |
Beta Was this translation helpful? Give feedback.
-
This could have very negative implications for the user experience in the IDE. Right now we extensively take advantage of keywords to provide appropriate parsing resync points. If all keywords are actually just identifiers then it becomes massive harder to actually tell what's going on. Remember that an IDE experience almost always is involved when the code is in error, not when the code is correct. |
Beta Was this translation helpful? Give feedback.
-
I don't see how that would be the case. Say we introduced a new keyword "bar" and said "bar ( expr )" was a new syntactic construct we would recognize. If this is a keyword, then now you break existing code that people wrote that did that. On the other hand, if you say "we'll first see if the old interpretation is valid, accept it if it is, and then otherwise fallback to the new interpretation", then that's exactly what we already do today. That's how we added "nameof" to the language. So i'm not seeing what this actually buys us. We already have an approach that allows us to add new 'keywords' to the language in a way that doesn't break things. I'm not seeing why that approach is currently problematic or needs some new system to address it. |
Beta Was this translation helpful? Give feedback.
-
@CyrusNajmabadi = Well it's probably academic because C# is simply unable to ever support this. I don't think an IDE would be any different so long as the language has a grammar which it would.
Well that's not true - the C# grammar does not enable us to add new arbitrary keywords, it was never designed to - unfortunate but that's its C heritage. |
Beta Was this translation helpful? Give feedback.
-
But it does. That's how we've added new keywords into the language. We just make the 'contextual'. Which is precisely what you want. Something which is a keyword in one place, but which can be used like an identifier elsewhere without breaking things. |
Beta Was this translation helpful? Give feedback.
-
There used to be a language named PL/I (or PL/1 sometimes) that had no reserved words, this seemed odd to me when I first encountered it because people would explain that this (for example) was perfectly legal:
and so on.
However I discovered that the true motivation for this was to make the language extensible, adding new keywords never broke older code that may have used these keywords as names for things.
I want to suggest that the csharp language be enhanced to support this, then it will be trivial for the language designers to add new keywords without breaking any existing code.
However the C# grammar may itself prevent this - I haven't looked into it deeply.
Beta Was this translation helpful? Give feedback.
All reactions