So C did pre-emptively reserve certain words? Like island, strong, together..
I wonder if that paid off in some cases?
Or to ask differently, if one would design a new programming language (now), would you consider reserving words in advance?
I'm currently making a language, and yes, I'm reserving words for it because I want an easy C ABI. But I'm also making them easier to avoid.
Here's my list of reserved words:
* Anything that begins with `y_`.
* Anything that begins with `yc_`.
* Anything that begins with `YC_`.
* Anything with three or more consecutive underscores.
* Edit: Anything that begins with an underscore. This is because my language will be able to transpile to C if necessary.
The first is for types and items in the standard library (the language's name is Yao, so a `y` makes sense). The second and third are for the C ABI (hence, `yc`) and for historical reasons. `YC_` in particular is for C macros.
The last is for name "mangling." I put it in quotes because my language's standard name mangling (it will be the same across every implementation) will not really mangle the names. Instead, it will concatenate them, using five underscores between package names, four underscores between packages and items in a package, and three underscores between an item and its suffix. (For overloaded functions, the programmer has to define a suffix for each one. That suffix is how their names will be different in the C ABI.)
My hope is that these rules will not be too onerous. I don't think the reserved prefixes are used much, and I haven't seen anyone use more than one consecutive underscore, though I'm allowing one more, just in case.
It's unfortunate POSIX didn't adopt a similar convention for its reservations, like a psx_ suffix for its namespace. But I guess with POSIX it was more ratifying established *NIX things as a standard they could all easily agree on without too much disruption.
‘y_’ is too strict in my opinion. You declare lots of variables like y_1 or y_ans when you write any sort of numerical calculation code (like in games or physics simulations).
It seems too strict, but I should clarify: these rules only apply to the C ABI.
Declaring variables with those names actually will not conflict if they are done in pure Yao. There's a special way to access the C symbols of functions and types, and it's deliberately different, for this very purpose.
Ah if that’s only for the C ABI then that’s much better. I still see someone writing numerical algorithms might use y_* as one of the arguments, though the probability is a lot more slim.
The restriction isn't on `y[c]_`. It's actually on `y[c]___`.
This is because `y` is the package name for the standard library, and the standard library name will always be separated from the rest of the name by 3 or more underscores.
Really, the restriction is on 3 or more consecutive underscores in C names, and you can't have have a package name that is either `y`, `yc`, or `YC`.
I apologize for the confusion. I was in a hurry and on mobile with the original post.
New languages usually support namespaces, which prevents the problem.
As for payoff, new versions of the C standard usually introduce new functions and macros with those name patterns, without breaking client code that respects the reserved-name rules.
I wouldn't hesitate to use island, strong, or together as a variable name, even though they are technically "reserved". Maybe avoid "strong", it's on the edge of being made into a reserved word. I'd stay away from "isnull", "strsplit", or "toint" or similar variable names though. Although "isNull", "strSplit", and "toInt" are still fine.
I think the idea of reserving keywords in advance is a good one, but not something that interferes with vocabulary words so easily. The idea is to be able to add a new keyword in the future without breaking code that uses that keyword itself currently.
The ES5 case is interesting because most of that list of "future reserved words" was a list of reserved words in ES4 "The Lost Version". That list also included fun things still not used like private, public, abstract, package, byte, int, volatile, synchronized.
One additional fun thing to note is that despite "private" already being reserved as a keyword TC-39 when they did somewhat recently add private fields to classes a few years back decided on "hash names" over the private keyword.
It's pre-emptively reserving certain prefixes. "is" is for any function that returns true/false (which then collides with "island", "israel", "isaac"). "str" for any string function (which then collides with "strong", "strepthroat", "strange").
I wonder if that paid off in some cases? Or to ask differently, if one would design a new programming language (now), would you consider reserving words in advance?