Are there good reasons to minimize the number of keywords in a language?

Question

Are there good reasons to attempt to keep the number of keywords/reserved tokens in a language to a minimum? Such as by repurposing existing keywords for new syntax instead of adding new ones. Related: Why do some programming languages choose to have a dedicated keyword for elseif instead of using else + if like in C?

I suspect that more keywords may make implementing a compiler more complicated, slower as there are more keywords to compare tokens against or similar. But are these concerns legitimate and are there other advantages to having/maintaining a low number of keywords?

Answer 1

Historical Baggage

If you've got a language that's already been released, then adding a new keyword is almost always a breaking change, since anyone who happened to use that name as a variable or function is now going to get a parse error.

Bjarne Stroustrup has stated that the bizarre pure virtual function syntax in C++ was designed in that way to avoid having to convince the committee to add a new keyword "pure" to the language. Instead, we got

virtual void example() = 0;

Some languages get around this by defining "soft keywords". For instance, the new match / case statement in Python only treats the keyword specially when appearing as part of the statement, so match = 1 is still valid and creates a variable called match. But this massively complicates parsing.

Answer 2

Reducing the number of reserved words

You normally can't name identifiers the same as keywords. That might be inconvenient. You may want a variable named class representing the HTML class attribute, or a function named catch.

Keywords are typically short verbs which are likely to conflict with functions or short variables.

You can have keywords that are not reserved by allowing them only in some situations. For example in Javascript in for (x of y) of is a keyword yet you can name your identifier of in other contexts.

More keywords should not make the compiler slower, in fact it is probably very slightly faster than aliasing keywords to multiple meanings that most languages use.

Answer 3

TL;DR: No.

You raise a number of points, and a number of answers were given. I'll play Devil's Advocate and refute most/all of them.

Compiler Complexity and Performance

I suspect that more keywords may make implementing a compiler more complicated, slower as there are more keywords to compare tokens against or similar

On the contrary.

Compiler complexity is typically proportional to the number of concepts that the compiler has to deal with, and how much context the compiler needs to reconstruct (type inference, for example).

Using concepts with no keywords, or overloading keywords to mean multiple concepts in different contexts increases the amount of information the compiler must re-calculate (that the developer knew about) and therefore slows down compilation.

From a compiler perspective, one concept = one unique keyword is actually best.

Backward Compatibility

Or the inability to introduce a new keyword because it would prevent compiling older programs.

This is certainly an issue in many languages. Work-arounds include:

• Using non-keywords: C++ uses = 0 for pure virtual functions, for example.
• Using contextual keywords: C++ uses final and override as keywords only in function declarations.
• Overloading existing keywords: C++ uses static in 4 different ways, with drastically different meanings.

And demonstrates an embarrassing lack of foresight.

A modern¹ language should plan for evolution, and thereby figure out a solution to be able to introduce keywords without breaking backwards compatibility.

Examples:

• Prefixing: if keywords start with :, and identifiers cannot, then there's no clash possible.
• Versioning: in Rust, each edition introduces new keywords, and users opt-in to the new editions, fixing their code as they do².

Thus, in a properly crafted language -- easier in hindsight -- there is no backward compatibility issue in adding keywords.

¹: By which I mean a language created nowadays, with over 50 years of hindsight.

²: This is supported by another feature, which allow importing identifiers from previous versions, called Raw Identifiers. In essence, it applies the sigil strategy to identifiers (exceptionally), rather than keywords.

Reducing Reserved Words

There are many kinds of keywords.

The "traditional" keyword is reserved at all scopes, and there may be indeed a desire to keep that number low. There are, however, also contextual keywords, which are only keywords in certain contexts.

As an example, consider the (dubious) Rust test case:

fn union() {
    union union<'union> { union: &'union union<'union>, }
}

union is a keyword, when introducing an item, but otherwise can be used as function name, type name, lifetime name, and field name.

Other approaches to avoid "encroaching" on user variables exist, such as the unpopular option of prefix every keyword with a specific sigil³.

³ In this Rust example, single-quote is used as a sigil for lifetimes.

Simplicity and Learning Curve

The difficulty in learning a programming language is generally about semantics -- concepts -- and libraries -- standard or 3rd-party.

Having a single unique keyword for every concept is actually helpful for learners, as they make it easy to:

1. Recognize concepts they have not learned yet.
2. Search for them -- by keyword! -- on the web.

Keyword-less approaches, or keywords overloading, make a programming language less discoverable as it makes formulating web search queries more difficult, and reduces the pertinence of the search results.

Conclusion

One may want to reduce the number of concepts to keep a language simpler, both for users and compiler-writers.

Reducing the number of keywords without reducing the number of concepts, however, is foolish. If anything, it makes the language harder to learn.

On the other hand, one may want to use mostly contextual keywords, to avoid reserving too many desirable user-defined names.

And of course, one should plan for evolution and have a plan to introduce new keywords in the future. External versioning is a potential solution.

Answer 4

You can simply use one of the lexerless parsing approaches (e.g., PEG), and then you would not need to worry about keywords. Your special meaning keywords will only be recognised as such when they make sense in a context, and you can still use the same words anywhere else (e.g., if or for as variable names, etc.).

Answer 5

Simplicity and Learning Curve

The less keywords and the more intuitive and related they are, the more simple and, as a such, easy to learn the language is. This is very useful especially in beginner languages.

Answer 6

I suspect that more keywords may make implementing a compiler more complicated, slower as there are more keywords to compare tokens against or similar

This is probably unfounded. There are two parts to it:

• The lexer has to tell whether a token like while or count is a keyword or an identifier. This can be done by looking up the string in a hashtable, which takes O(1) time independently of the number of keywords.
• When the parser sees a keyword token, it has to branch on the kind of keyword; for example, on an if token call parseIfStmt, on a while token call parseWhileStmt, on a throw token call parseThrowStmt and so on. This can be done in a switch statement which can be compiled to something more efficient than just checking the keywords one-by-one. If the lexer has already reduced keywords from strings to enum values, then a dense switch can use a jump table, whereas if they are still strings then a hashtable is a good option. Either way, the time taken to choose the right branch doesn't have to scale with the number of keywords.

So having more keywords probably has very little effect on the compiler's performance, in and of itself.

That said, having more concepts in the language might mean the compiler has more work to do after parsing, and if the additional concepts in the language correspond with additional keywords then these two things would be correlated.

Answer 7

You can have Zero reserved keywords if you want, and this can be useful if you want users to define their own language extensions in yours.

Take a simple reserved keyword like the predefined type int: while it is a predefined type, it could belong in a specific package/module, the standard library. You could name it std.int and free the name int for other usages. User-defined modules could have their own int types.

And this can apply to keywords that are used to structure your source code, for example:

class MyClass {
};

fn f() {
};

The class or fn keywords are necessary here to know how to parse the following text. They are present at the syntactic level of a parser, but maybe you can avoid that and have a more regular parser and a single keyword declare:

declare(std.class)(MyClass){
}

declare(std.fn)(f, ()) {
}

Here, std.class and std.fn are identifiers that the compiler knows how to handle under the declare expression. They are not special anymore on a syntactic level, they are identifiers in a namespace for which the language specifies a behavior.

Each declaration has the same syntax, and it can be extended to include things like final, static, mutable, etc.

In the case of iterators like for, while etc. you can also imagine that they are standard std.for etc. identifers that the compiler knows how to interpret, all under the iterate keyword.

So now, we introduced both a declare keyword and an iterate generic keywords, but they are similar and could be merged as a single magic keyword:

magic(std.class)(MyClass) {
}

magic(std.for)(i, 0, 100) {
}

Your compiler can detect if the argument list of the std.for is malformed, the error detection is moved from the lexer/parser to one step further in the compiler where you check if syntactically well-formed expressions are meaningful.

And if you make all your syntax even more regular, you can avoid completely the magic keyword, which is how you end up with Lisp:

(cl:defclass my-class () ())

(cl:defun foo (a b c) ...)

(cl:loop ...)

All the predefined symbols that name types, functions, macros, special operators, etc. belong to the "COMMON-LISP" package (nicknamed cl), you can have your own loop, defun or defclass functions, macros or compiler-macros in your own package.

Answer 8

If you had many you can add more

If your language already had many keywords, you can add more.

For example you can define + operator in class:

def __add__(...):
    ...

This code is clear, but if your language had many keywords, you can add more:

public static int operator +(..., ...) {
    ...
}

Answer 9

Conciseness

Keeping the number of keywords to a minimum reduces the chances that the developer will need to pick longer, more descriptive names. This means that the language will also be more concise and readable, in most cases.

As well as making the language more concise, reducing the number of keywords prompts the designer to pick more descriptive words, as keywords must be used sparingly.