4 ms·
Ambiguity in the language is a whole problem of its own. Ambiguity in parsing is also ambiguity in writing, so a language should avoid it all cost. It's true t
by chton 12y ago
Ambiguity in the language is a whole problem of its own. Ambiguity in parsing is also ambiguity in writing, so a language should avoid it all cost. It's true that forcing actions to come with extra words is a way to do that, but it's by no means the only one. It's possible to strive for non-ambiguity without extra syntax.
A good example of this case would be Java (like it or not):
String Hello(String name) {
String greeting;
greeting = "hello " + name;
return greeting;
}
Say of the braces and the semicolons what you will, but the core syntax is unambiguous and doesn't have a single word that doesn't have semantic meaning.
- scott_s 12y agoI was exclusively talking about parsing ambiguity. Using a keyword to introduce entity definitions (variables, functions, packages, etc.) gives the language more space to grow in syntax without worrying about such ambiguities later. You can construct a grammar without any ambiguities that does not use such keywords - such as with your example of Java - but you're going to have to keep this pitfall in mind anytime you change the grammar.
- chton 12y agoThat's true, it does make it easier to evolve the syntax. The negative side of demanding a terse syntax is clear enough in the C# 6 changes (http://msdn.microsoft.com/en-us/magazine/dn683793.aspx http://msdn.microsoft.com/en-us/magazine/dn683793.aspx), which are really showing a lot of bloat. It's possible to debate the positive side too, but I do agree that constructing a language with a verboser non-semantic grammar is easier.
- scott_s 12y agoFor things like "var" and "def", I'm coming to see them as a smidgen of up-front verbosity to prevent much later monstrosities.
- seanmcdirmid 12y agoYou are completely ignoring error recovery, which these days of language-aware IDEs is much more important than optimal conciseness.