Programming Language Design and Implementation Stack Exchange is a question and answer site for designers and implementers of computer programming languages. It only takes a minute to sign up.
Sign up to join this community
In Go, capitalized identifiers are public (exported), while lowercase identifiers are private (within the package it's defined in). Most other programming languages don't have this sort of semantic difference of public/private by capitalization.
Cognate ignores non-capitalized tokens to allow for more natural language-looking code. Most programming languages don't have this due to their case-sensitivity for identifiers.
What are the pros and cons of semantically significant capitalization?
Most programing langues nowadays support unicode identifiers. This allows writing identifiers in languages other than english. However, capitalization does not exist in every language and may have other roles than in English.
Is מזהה public or private? You can't really tell. People writing code in such languages will be forced to prefix their identifiers with latin letters to get the desired behavior. Not an ideal situation.
Even in languages that have the concept of capitalization it may not be trivial to substitute a lower case word with one that starts with a upper case. For example in Greek different cases of constants have different meanings.
Using Go as an example, if you have a private identifier and want to make it public, you have to effectively rename it, which means changing code at every point where the identifier is used, as opposed to just changing the declaration. And since there are only two letter cases, it prevents the language from adding another option, such as some kind of partially exported identifiers.
As another example, if a language uses capitalization to distinguish between types and variables, it's going to cause problems if you later want to add the ability to use types as values (“first-class types”):
#private fields are another example where you have to rename things to change their visibility.
$\endgroup$
Cons:
You move representation of a binary property into the identifier concept. Go is actually a good example of why this is a bad idea. With their decision, they are now stuck with a binary visibility concept. Most language have either nothing ore a lot more granularity than that. The Go way, you can't share definitions between an API and an implementation package.
For most languages, there is syntax highlighting which allows you to colorize the visibility definition and ignore it, if you don't care.
The highlevel point against is that such decisions are usually made at a stage where the language is still very simple and the decision looks reasonable. However, languages get more complex if they are successful. But such fundamental decisions cannot be undone in a compatible way. Adding another keyword or braces where they weren't allowed before is a mostly or completely compatible change.
Case has long been used by convention to indicate roles of identifiers. For instance, in C it's conventional to use ALLUPPER for macros, and either snake_case or camelCase for other identifiers. In many languages, classes are conventionally named with an initial uppercase letter; this usually goes along with camelCase for the rest of the name.
Making this semantically significant simply formalizes these common programming styles. It's analogous to the way languages like Python make indentation significant to the parser, rather than it just being used to make the code easier for humans to read.
So the main "pro" is that programs in the language are forced to follow a consistent style, making it easier for everyone to read each other's programs.
This can also make it easier for programming tools to provide assistance.
The con, as other answers say, is that it doesn't work well when programming in (human) languages that don't have upper/lowercase similar to Latin alphabets.
bool is a macro expanding to _Bool, dating back to C99. There is often a getc macro in <stdio.h> implementations. Lower cased macros are used for shortening nested member access in structures: #define s6_addr in6_u.u6_addr8. It would be bad for macros to be restricted to upper case or even a leading upper case character.
$\endgroup$
getc() is specified as a function, but built-in functions are allowed to be implemented as macros. I think bool is an exception because it was originally an implementation extension keyword, and when it became a standard macro they kept the lowercase name for compatibility.
$\endgroup$
errno symbol from <errno.h> is explicitly defined a macro in ISO C which "expands to a modifiable lvalue". The behavior is undefined if a program uses #undef on it to access an errno object. In <stdio.h>, stdin, stdout and stderr are also defined as macros. (And have were that way in ancient Unix; something along the lines of #define stdin __filetab[0] or whatever.) In <assert.h>, assert is a macro.
$\endgroup$
errno because of multi-threading).
$\endgroup$
One advantage is that you can lexically distinguish between two different classes of identifier, which could be useful if they need to be parsed differently.
A good example of this is Haskell, which uses capitalized identifiers to denote types, and non-capitalized for functions. This avoids the need for its parser to determine based on the context which kind of identifier it is looking at, and results in a simpler, more efficient parser.
Con: screenreaders typically either don’t announce all-caps any differently to lowercase words, or, worse, can read them letter by letter as if they were an abbreviation.
Language developers shouldn’t bake in inaccessible practices into the base system.
Similar to occipita's answer, but for humans instead of compilers:
When reading code, it can be useful to immediately be able to tell whether a given identifier is public or private, without going to find its definition (using the example of Go). This will make it easier to pick out identifiers that definitely came from the current file, and which might have come from elsewhere. It might also allow you to make quicker and better decisions on whether you can safely change a function: if it's capitalised, then it's likely to be used somewhere else in the codebase, so changing it might be riskier.
There are only two cases. It can be a hard time if, for example, we need to add protected support to a newer version of the language.
For example, in JavaScript, objects are often used as maps, and class properties can be dynamic too. A static analyser cannot tell if obj.x is accessing a private property, or reading the value corresponding to a user input x.
Some words are written in specific cases. For example, forcing iOS to be ios or IOS at language level can be a bit ugly.
