5 ms·

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 desi

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?

kzrdude 4y ago
If you reserve something in a new language, you'd properly make it an error to use it.
klodolph 4y ago
ES5 had "future reserved words" including class, const, export, import, and let.
- livrem 4y ago
  Java has goto and const as reserved keywords. Source: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...
- kps 4y ago
  C orignally had `entry` as a reserved work (from Fortran 77, where a function could have multiple entry points).
- WorldMaker 4y ago
  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.
  - WorldMaker 4y ago
    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. class Example { #privateFieldName } Rather than: class Example { private privateFieldName } The debate on that was pretty interesting.
gavinhoward 4y ago
Programming language designer here. 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.
- pengaru 4y ago
  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.
- cyber_kinetist 4y ago
  ‘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).
  - gavinhoward 4y ago
    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.
godshatter 4y ago
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.
layer8 4y ago
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.
D-Coder 4y ago
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").

kzrdude 4y ago

If you reserve something in a new language, you'd properly make it an error to use it.

klodolph 4y ago

ES5 had "future reserved words" including class, const, export, import, and let.

livrem 4y ago
Java has goto and const as reserved keywords. Source: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...
kps 4y ago
C orignally had `entry` as a reserved work (from Fortran 77, where a function could have multiple entry points).
WorldMaker 4y ago
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.
- WorldMaker 4y ago
  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. class Example { #privateFieldName } Rather than: class Example { private privateFieldName } The debate on that was pretty interesting.

gavinhoward 4y ago

Programming language designer here. 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.

pengaru 4y ago
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.
cyber_kinetist 4y ago
‘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).
- gavinhoward 4y ago
  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.

godshatter 4y ago

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.

layer8 4y ago

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.

D-Coder 4y ago

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").