<h2>Preamble</h2>
<p>As you probably know, keywords are special reserved words in a programming language that have specific meanings and purposes and can’t be used for anything but those specific purposes.</p>
<p>An example of a keyword in Python 3 is <code>False</code>, which you cannot use as a variable at all:</p>
<pre class="lang-python prettyprint-override"><code>&gt;&gt;&gt; False = ''
  File &quot;&lt;stdin&gt;&quot;, line 1
    False = ''
    ^^^^^
SyntaxError: cannot assign to False
</code></pre>
<p>Built-ins could for example be a built-in function - for example, again from Python 3, the function <code>open</code>.</p>
<p><code>open</code> can actually be used as a variable - in which case you can no longer use it with its intended function until you remove it from scope:</p>
<pre class="lang-python prettyprint-override"><code>&gt;&gt;&gt; open = 'hey' # we've overwritten open as our own variable in the current scope
&gt;&gt;&gt; open('file')
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;
TypeError: 'str' object is not callable
&gt;&gt;&gt; del open
&gt;&gt;&gt; open('') # open is now back as a built-in
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;
FileNotFoundError: [Errno 2] No such file or directory: ''
</code></pre>
<p>Variables colliding with keywords and built-ins could lead to the following:</p>
<ol>
<li>They could potentially remove words from the programmers vocabulary (examples in Python are <code>file</code> and <code>hash</code>)</li>
<li>They could potentially add confusion, bugs, and errors when programmers are allowed to overwrite them.</li>
<li>The IDE of the developer will color and potentially flag something as a keyword where the developer intended otherwise.</li>
</ol>
<p>And likely more, feel free to add.</p>
<h2>So, what options do we have to avoid collisions?</h2>

<syntax><language-design><variables>
What syntax options exist for avoiding variable names colliding with keywords and built-ins?
CC BY-SA 4.0
2023-05-23T10:40:42.287Z
The `id`  function in python is particularly annoying since it's common to want to name a variable that and the function itself is not very useful
mousetail 'he-him'
CC BY-SA 4.0
2023-05-23T20:53:59.820Z
can you please not put answers in the question post and please not lead the question in the question post?
starball
CC BY-SA 4.0
2023-05-24T09:31:24.380Z
@starball Part of the StackExchange model is to put information about what you've already tried, and what research you've already done, in the question. I don't think it's a problem. See [How to Ask](https://languagedesign.stackexchange.com/help/how-to-ask)
pxeger
CC BY-SA 4.0
2023-06-01T20:33:29.630Z
By far the most popular option is simply to forbid programmers to use the reserved words for anything but their defined purpose.
Mark
CC BY-SA 4.0
2023-08-21T16:58:13.740Z
@Mark Which leads to breaking changes when you add new keywords to the language. E.g. `rank` in MySQL became a reserved word when window functions were implemented.
Barmar
CC BY-SA 4.0
2023-09-02T16:14:44.163Z
Does this answer your question? [Preserving backwards compatibility when adding new keywords](https://langdev.stackexchange.com/questions/2310/preserving-backwards-compatibility-when-adding-new-keywords)
Karl Knechtel
<h2><code>var</code></h2>
<p>In almost all cases you list, the problem arises when using a storage name (variable) colliding with some previously declared entity, variable or not.</p>
<p>This can easily be avoided with explicit declaring any expected local storage name before utilization. In other words, declaring/reserving local variable names:</p>
<pre class="lang-python prettyprint-override"><code># Works. Have priority for anything in this scope
# &quot;var&quot; as contextual keyword where variable declaration is possible,

var False = ''
var var = False
open(var)

# Unrestricted MRO/global mutating
# Define a variable OR change something defined... where?

open = 'hey'
</code></pre>
<h2>Syntax option for alien, anything goes identifiers</h2>
<p>Some languages use <code>@</code> to explicitly define a user identifier (not only variables) that does not collide with keywords.</p>
<p>Taking inspiration from that, you could define an explicit syntax for all things &quot;this is an identifier, it does not collide with anything&quot; in language. The objective is not being convenient, but making it possible to interop with any external contexts.</p>
<p>Something like:</p>
<pre class="lang-python prettyprint-override"><code>var csv = CsvReader.Parse( text )
var name = csv.@'Column name with \0 and spaces at end '
</code></pre>

CC BY-SA 4.0
2023-08-21T16:15:16.140Z
2023-08-21T16:15:16.140Z
André L F S Bacci
<p>Kotlin and Swift, and probably others, allow keywords to be &quot;escaped&quot; with backticks, like <code>`if`</code>. Rust has the equivalent syntax <code>r#if</code> (the <code>r</code> stands for <a href="https://doc.rust-lang.org/rust-by-example/compatibility/raw_identifiers.html" rel="noreferrer">&quot;raw&quot;</a>).</p>

CC BY-SA 4.0
2023-05-23T12:28:07.660Z
2023-05-23T12:43:37.113Z
2023-05-23T12:43:37.113Z
pxeger
CC BY-SA 4.0
2023-05-23T12:30:41.390Z
There is a RFC currently being considered to allow `k#if` for keywords. This would allow you to use newer keywords in older rust editions before they become reserved
mousetail 'he-him'
CC BY-SA 4.0
2023-08-20T13:51:00.043Z
In C#, the syntax `@if` can be used to "escape" keywords when used as identifiers.
kaya3
CC BY-SA 4.0
2023-08-20T13:52:43.560Z
SQL's escape mechanism is similar, allowing table/column names that would otherwise be keywords.
Toby Speight
CC BY-SA 4.0
2023-09-06T15:02:38.817Z
Note that Rust is about [raw identifiers](https://doc.rust-lang.org/rust-by-example/compatibility/raw_identifiers.html), that is `r#if` is used when you want a variable called `if` despite `if` being a keyword.
Matthieu M.
<p>For builtin functions/variables, (but not syntactically special keywords), some languages let you &quot;opt out&quot; of having them implicitly in scope, with a special import statement at the top of the file.</p>
<p>For example, in Haskell:</p>
<pre class="lang-haskell prettyprint-override"><code>import Prelude hiding (head)
-- now you're free to define your own function called head
head = 123
main = print head
</code></pre>
<p><a href="https://ato.pxeger.com/run?1=NY47DsIwEET7nGI6oHABNDTcgStY8RqvcNbRslaUs9CkQZyJ24D5NKPRjEbzbo_krxfKeVnu1aI7PI2HsajhpJRrICQOLGesE_mw6ZyDlAlzqSslRCWCFQSKLNRSRZkEsUpvXAS9z5kC2rZrgiO2u303eJa3HZXFPuX3-4fwR3kB" rel="noreferrer">Try it online</a></p>
<p>and in Elixir:</p>
<pre><code>import Kernel, except: [if: 2]

if = 123
IO.puts(if)
</code></pre>
<p><a href="https://ato.pxeger.com/run?1=m70sNSezIrNowYKlpSVpuhY3TTJzC_KLShS8U4vyUnN0FFIrklMLSqwUojPTrBSMYrm4MtMUbBUMjYy5PP31CkpLijUy0zQheqFGwIwCAA" rel="noreferrer">Try it online</a></p>
<p>This is particularly useful in Elixir, because a lot of what you might expect to be keywords are in fact implemented as macros in the standard library (although Elixir does still have <a href="https://hexdocs.pm/elixir/1.14/syntax-reference.html#reserved-words" rel="noreferrer">reserved words</a> and <a href="https://hexdocs.pm/elixir/1.14/Kernel.SpecialForms.html" rel="noreferrer">special forms</a>, which, as far as I know, can't be excluded)</p>
<p>What syntax exactly you choose for this will depend on how you want it to fit in with your usual import syntax. Or maybe you could have a more special declaration that's unrelated to imports, like <code>@no_builtin(&quot;head&quot;);</code> or something.</p>

CC BY-SA 4.0
2023-05-23T12:44:23.450Z
2023-05-24T08:59:59.577Z
2023-05-24T08:59:59.577Z
pxeger
<p>APL uses four techniques:</p>
<ul>
<li><p>The core language is entirely symbolic, meaning that the most common operations do not need any alphabetical names at all. Not only do all mathematical built-ins have glyphs, even things like length, reverse, stringify, eval and table lookups have symbols.</p>
</li>
<li><p>Things that occupy normal syntactic roles (arrays, functions, and high-order functions) are prefixed with a &quot;quad&quot; (<code>⎕</code>) which is a stylised &quot;box&quot; referring to the box, or system, you're working on. These are called <em>system names</em>. E.g. <code>⎕NULL</code> is a <em>system constant</em>, <code>⎕CT</code> is the <em>system variable</em> for Comparison Tolerance, <code>⎕MKDIR</code> is a system function, and <code>⎕S</code> is the PCRE higher-order function for Searching.</p>
</li>
<li><p>Control structures and various declarations are prefixed with colon (<code>:</code>), indicating their kinship with labels, which are normal identifiers but are separated from the rest of the code line with a colon. E.g. <code>:If</code> begins a conditional and <code>:Access public shared</code> is used in object oriented programming.</p>
</li>
<li><p>Built-in APL objects have names, properties, methods, and events. While programmer-defined object members are directly referenced using <code>this.that</code> syntax, the built-ins are by default only reachable through dedicated system functions. E.g. one creates a new Timer object using the <em>string</em> <code>'Timer'</code> (e.g. <code>⎕NEW 'Timer' 5000</code>) and one can thereafter use the <code>⎕WG</code> system function to Get the value of a property (e.g. <code>⎕WG 'Interval'</code>) and the <code>⎕WS</code> system function to Set a property (e.g. <code>⎕WS 'Interval' 1000</code>). If one needs frequent access to members of a particular object and doesn't need to put custom members there, one can set the <code>⎕WX</code> system variable to eXpose the member names directly, thus occupying certain names. Similarly, events can be put on the queue using the <code>⎕NQ</code> (&quot;eNQueue&quot;) system function, and pending events can be handled using the <code>⎕DQ</code> (&quot;DeQueue&quot;) system function.</p>
</li>
</ul>
<p>This has the, in my opinion, huge benefit that all identifiers are (by default) freely available to the programmer, with no need to remember the reserved words. At the same time, the language developers can always add more system names, keywords, built-in objects, and built-in object members without risking collision with any existing code.</p>

CC BY-SA 4.0
2023-05-23T10:50:28.073Z
2023-08-20T13:41:13.330Z
2023-08-20T13:41:13.330Z
Adám
CC BY-SA 4.0
2023-05-23T10:57:52.607Z
This seems to work basically the same as PHP's $ except it's the opposite, functions and keywords are prefixed while variables are not
mousetail 'he-him'
CC BY-SA 4.0
2023-05-23T11:03:50.987Z
@mousetail Maybe I should add that good APL code shouldn't contain many of the prefixed names, providing for a cleaner look than had it been the user-defined names that were prefixed.
Adám
CC BY-SA 4.0
2023-05-23T11:06:35.333Z
So you are saying prefixing is optional in case there are no variables with the same names?
mousetail 'he-him'
CC BY-SA 4.0
2023-05-23T11:11:13.563Z
@mousetail No, the prefixed names *always* need prefixing. However, one can activate direct access to built-in members of built-in objects, so it isn't necessary to use a system function to access them.
Adám
CC BY-SA 4.0
2023-06-01T21:02:00.813Z
You forgot to mention the fact that most of the commonly used subset of APL is symbolic, so there's even less chance (not that there was any) of collision
Seggan
CC BY-SA 4.0
2023-06-01T21:28:32.373Z
@Seggan Good point — added. Somehow, I got into my head that it was talking about everything *but* "operators".
Adám
<p>Common Lisp's package system is one solution: make all built-ins members of a predefined namespace that is imported in all modules by default.</p>
<p>So for example the word <code>if</code> is likely a built-in special form. So make it synonymous with a symbol named <code>if</code> from a predefined package, like <code>std::if</code>. That a program can define its own symbol (say <code>user::if</code>) if it is really necessary, then predefine a hierarchy of namespaces to import from, so that if there is a user-defined <code>user::if</code> then it is chosen in preference to <code>std::if</code>, if the current file spells it simply as <code>if</code>.</p>

CC BY-SA 4.0
2023-05-23T21:01:35.020Z
2023-05-23T21:50:18.263Z
2023-05-23T21:50:18.263Z
finnw
CC BY-SA 4.0
2023-08-21T17:02:10.570Z
If you shadow `if` in your local package, you have to write `cl:if` throughout to access the "real" `if` form.
Barmar
<p>Smalltalk just doesn’t care. <code>true</code> and <code>false</code> are just global variables. This has the advantage that it makes the interpreter simpler in some ways, but it also means that you can break a lot of things by just saying <code>true become:false.</code></p>

CC BY-SA 4.0
2023-05-23T11:03:32.043Z
2023-05-23T11:03:32.043Z
Bbrk24
CC BY-SA 4.0
2023-05-23T11:05:41.923Z
You can do the same in Javascript and many other languages, as stated in the question with the `open` example
mousetail 'he-him'
CC BY-SA 4.0
2023-05-23T11:20:28.823Z
Overwriting built-in functions is rather different than overwriting `true` and `false`, though.
Bbrk24
CC BY-SA 4.0
2023-05-23T11:21:04.037Z
Well built in functions are just global constants just like true and false are
mousetail 'he-him'
CC BY-SA 4.0
2023-05-24T11:05:33.037Z
Smalltalk doesn’t even have “if” and “else” keywords, instead its booleans just have `ifTrue:` and `ifFalse:` methods. It’s often said that the only keywords in Smalltalk are self, super, true, false, nil, and thisContext.
Bbrk24
<p><strong>Put a dot in the keyword.</strong></p>
<p>This is an idea from my language that requires keywords to have fully-qualified package names.</p>
<p>In my language, users can define their own keywords, which are then referred to in the same way items in external packages are: the package name, dot, then keyword.</p>
<p>This has a side effect that I can put keywords in the standard library in subpackages in the standard library, and those keywords will not collide with variables.</p>
<p>For example, say I had a <code>print</code> keyword like Python 2. I could put it in the <code>io</code> subpackage, and then I could do this:</p>
<pre><code>import io;

io.print &quot;stuff&quot;;
</code></pre>
<p>and the user could still use <code>print</code> as a variable name.</p>
<p>You can do this even in a language without such things, though. Just make the keyword <code>io.print</code> instead of just <code>print</code>.</p>
<p>The key point is that the <strong>keyword doesn't have to follow the same rules as an identifier</strong> because it's special. You can put whatever characters you want in it, including characters that don't belong in identifiers.</p>

CC BY-SA 4.0
2023-06-01T18:45:57.703Z
2023-06-01T18:45:57.703Z
Gavin D. Howard
CC BY-SA 4.0
2023-06-01T21:54:02.960Z
ECMAScript too has this, but when defining an item you may need brackets there. In my ECMAScript-based language I supported an escaped identifier token for allowing defining items instead of using brackets.
Hydroper
CC BY-SA 4.0
2023-07-21T07:24:08.750Z
In this example, the keyword `import` doesn't contain a dot.
tobyink
CC BY-SA 4.0
2023-07-21T21:53:34.403Z
@tobyink keywords don't *have* to contain dots. They just can.
Gavin D. Howard
CC BY-SA 4.0
2023-07-24T16:07:16.443Z
@GavinD.Howard but if variables can be dotless and keywords can be dotless, they can still collide.
tobyink
CC BY-SA 4.0
2023-07-25T17:39:01.143Z
@tobyink yes, but there's always a set of keywords that people avoid anyway. I meant my answer more in the context of "how do I add keywords when I have to be backwards compatible?"
Gavin D. Howard
<p>C# escapes keywords with <code>@</code>:</p>
<blockquote>
<p>Keywords are predefined, reserved identifiers that have special meanings to the compiler. They can't be used as identifiers in your program unless they include <code>@</code> as a prefix. For example, <code>@if</code> is a valid identifier, but <code>if</code> isn't because <code>if</code> is a keyword.</p>
</blockquote>
<p>Documentation: <a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/</a></p>

CC BY-SA 4.0
2023-08-20T14:49:30.840Z
2023-08-20T14:49:30.840Z
André L F S Bacci
<blockquote>
<p>What options do we have (to tell apart keywords and programmer-specified names)?</p>
</blockquote>
<p>[Well this is a rather open-ended ended question and there are a few answers already, but here are some ideas I didn't see mentioned.]</p>
<p>You could remove all ambiguity between the two by making them have different naming restrictions.</p>
<p>For example, requiring capitalization in one but not the other. E.g. if names that start with an uppercase letter were reserved for keywords, you could have something like this, where <code>if</code> is a regular variable and <code>For</code> and <code>If</code> are the usual compound constructs:</p>
<pre><code>For if in interfaces:
    If if = mainInterface: 
        ...
</code></pre>
<p>Of course reserving names with uppercase initial letters would prevent the <code>CamelCase</code> naming style, but would still allow <code>camelCase</code> with a lower case initial character, and <code>snake_case</code>. Names starting with acronyms and the convention of writing some constants in all uppercase might be a problem though.</p>
<p>Having to hit shift when writing keywords might be an annoyance for some, but I think it's somewhat comparable to typing long variables with upper and lower case letters. Both can be alleviated with a smart editor, since in <em>most</em> cases it's likely that e.g. a programmer writing the C-like <code>if ( a == b )</code> means it as the start of a conditional structure, and not a function call, even if the keyword was really <code>If</code>.
Well at least as long as a function called <code>if</code> was not defined, anyway, but there are always limits to automatic correction.</p>
<hr />
<p>As a more extreme variant, you could make every user-defined name carry some sort of a type identifier. The <code>$</code> / <code>@</code> / <code>%</code> sigils in variable names in Perl would be something like this, but you'd need to extend it to e.g. function names too.</p>
<p>E.g. with variables marked with a <code>$</code>, functions marked with a <code>&amp;</code>, and the keyword unadorned, this should be technically unambiguous:</p>
<pre><code>if &amp;if($if):
    ...
</code></pre>
<p>Or do that the other way around, by having keywords contain some special character:</p>
<pre><code>!if foo(if):
    ...
</code></pre>
<p>Even though some languages get away with mandatory sigils with variables, I expect this would be perceived as unnecessarily ugly by a few programmers. Also, there's more typing effort in that special characters are usually a bit harder to key in than letters regardless of case, and sometimes outright annoying in many keyboard layouts. E.g. Northern European keymaps have <code>[</code> at AltGr+8, and even Shift-1 for <code>!</code> requires reaching a bit farther than Shift-i for <code>I</code>.</p>

CC BY-SA 4.0
2023-08-29T05:28:46.200Z
2023-08-30T08:44:26.287Z
2023-08-30T08:44:26.287Z
ilkkachu
# What syntax options exist for avoiding variable names colliding with keywords and built-ins?
Posted by: username_0 on 2023-05-23
Preamble
As you probably know, keywords are special reserved words in a programming language that have specific meanings and purposes and can’t be used for anything but those specific purposes.
An example of a keyword in Python 3 is False, which you cannot use as a variable at all:
>>> False = ''
  File "", line 1
    False = ''
    ^^^^^
SyntaxError: cannot assign to False

Built-ins could for example be a built-in function - for example, again from Python 3, the function open.
open can actually be used as a variable - in which case you can no longer use it with its intended function until you remove it from scope:
>>> open = 'hey' # we've overwritten open as our own variable in the current scope
>>> open('file')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'str' object is not callable
>>> del open
>>> open('') # open is now back as a built-in
Traceback (most recent call last):
  File "", line 1, in 
FileNotFoundError: [Errno 2] No such file or directory: ''

Variables colliding with keywords and built-ins could lead to the following:

They could potentially remove words from the programmers vocabulary (examples in Python are file and hash)
They could potentially add confusion, bugs, and errors when programmers are allowed to overwrite them.
The IDE of the developer will color and potentially flag something as a keyword where the developer intended otherwise.

And likely more, feel free to add.
So, what options do we have to avoid collisions?
**Tags:** syntax language-design variables
> **Comments:**
> **username_1**: The `id`  function in python is particularly annoying since it's common to want to name a variable that and the function itself is not very useful  
> **username_2**: can you please not put answers in the question post and please not lead the question in the question post?  
> **username_3**: @starball Part of the StackExchange model is to put information about what you've already tried, and what research you've already done, in the question. I don't think it's a problem. See [How to Ask](https://languagedesign.stackexchange.com/help/how-to-ask)  
> **username_4**: By far the most popular option is simply to forbid programmers to use the reserved words for anything but their defined purpose.  
> **username_5**: @Mark Which leads to breaking changes when you add new keywords to the language. E.g. `rank` in MySQL became a reserved word when window functions were implemented.  
> **username_6**: Does this answer your question? [Preserving backwards compatibility when adding new keywords](https://langdev.stackexchange.com/questions/2310/preserving-backwards-compatibility-when-adding-new-keywords)  
---
## 9 answers
### Answer by username_3 on 2023-05-23. Score: 11
Kotlin and Swift, and probably others, allow keywords to be "escaped" with backticks, like ``if``. Rust has the equivalent syntax `r#if` (the `r` stands for ["raw"](https://doc.rust-lang.org/rust-by-example/compatibility/raw_identifiers.html)).
> **Comments:**
> **username_1** (2023-05-23): There is a RFC currently being considered to allow `k#if` for keywords. This would allow you to use newer keywords in older rust editions before they become reserved  
> **username_8** (2023-08-20): In C#, the syntax `@if` can be used to "escape" keywords when used as identifiers.  
> **username_9** (2023-08-20): SQL's escape mechanism is similar, allowing table/column names that would otherwise be keywords.  
> **username_10** (2023-09-06): Note that Rust is about [raw identifiers](https://doc.rust-lang.org/rust-by-example/compatibility/raw_identifiers.html), that is `r#if` is used when you want a variable called `if` despite `if` being a keyword.  
---
### Answer by username_3 on 2023-05-23. Score: 11
For builtin functions/variables, (but not syntactically special keywords), some languages let you "opt out" of having them implicitly in scope, with a special import statement at the top of the file.
For example, in Haskell:
import Prelude hiding (head)
-- now you're free to define your own function called head
head = 123
main = print head

Try it online
and in Elixir:
import Kernel, except: [if: 2]

if = 123
IO.puts(if)

Try it online
This is particularly useful in Elixir, because a lot of what you might expect to be keywords are in fact implemented as macros in the standard library (although Elixir does still have reserved words and special forms, which, as far as I know, can't be excluded)
What syntax exactly you choose for this will depend on how you want it to fit in with your usual import syntax. Or maybe you could have a more special declaration that's unrelated to imports, like @no_builtin("head"); or something.
---
### Answer by username_11 on 2023-05-23. Score: 7
APL uses four techniques:

* The core language is entirely symbolic, meaning that the most common operations do not need any alphabetical names at all. Not only do all mathematical built-ins have glyphs, even things like length, reverse, stringify, eval and table lookups have symbols.
* Things that occupy normal syntactic roles (arrays, functions, and high-order functions) are prefixed with a "quad" (`⎕`) which is a stylised "box" referring to the box, or system, you're working on. These are called *system names*. E.g. `⎕NULL` is a *system constant*, `⎕CT` is the *system variable* for Comparison Tolerance, `⎕MKDIR` is a system function, and `⎕S` is the PCRE higher-order function for Searching.
* Control structures and various declarations are prefixed with colon (`:`), indicating their kinship with labels, which are normal identifiers but are separated from the rest of the code line with a colon. E.g. `:If` begins a conditional and `:Access public shared` is used in object oriented programming.
* Built-in APL objects have names, properties, methods, and events. While programmer-defined object members are directly referenced using `this.that` syntax, the built-ins are by default only reachable through dedicated system functions. E.g. one creates a new Timer object using the *string* `'Timer'` (e.g. `⎕NEW 'Timer' 5000`) and one can thereafter use the `⎕WG` system function to Get the value of a property (e.g. `⎕WG 'Interval'`) and the `⎕WS` system function to Set a property (e.g. `⎕WS 'Interval' 1000`). If one needs frequent access to members of a particular object and doesn't need to put custom members there, one can set the `⎕WX` system variable to eXpose the member names directly, thus occupying certain names. Similarly, events can be put on the queue using the `⎕NQ` ("eNQueue") system function, and pending events can be handled using the `⎕DQ` ("DeQueue") system function.

This has the, in my opinion, huge benefit that all identifiers are (by default) freely available to the programmer, with no need to remember the reserved words. At the same time, the language developers can always add more system names, keywords, built-in objects, and built-in object members without risking collision with any existing code.
> **Comments:**
> **username_1** (2023-05-23): This seems to work basically the same as PHP's $ except it's the opposite, functions and keywords are prefixed while variables are not  
> **username_11** (2023-05-23): @mousetail Maybe I should add that good APL code shouldn't contain many of the prefixed names, providing for a cleaner look than had it been the user-defined names that were prefixed.  
> **username_1** (2023-05-23): So you are saying prefixing is optional in case there are no variables with the same names?  
> **username_11** (2023-05-23): @mousetail No, the prefixed names *always* need prefixing. However, one can activate direct access to built-in members of built-in objects, so it isn't necessary to use a system function to access them.  
> **username_12** (2023-06-01): You forgot to mention the fact that most of the commonly used subset of APL is symbolic, so there's even less chance (not that there was any) of collision  
> **username_11** (2023-06-01): @Seggan Good point — added. Somehow, I got into my head that it was talking about everything *but* "operators".  
---
### Answer by username_13 on 2023-05-23. Score: 6
Common Lisp's package system is one solution: make all built-ins members of a predefined namespace that is imported in all modules by default.

So for example the word `if` is likely a built-in special form. So make it synonymous with a symbol named `if` from a predefined package, like `std::if`. That a program can define its own symbol (say `user::if`) if it is really necessary, then predefine a hierarchy of namespaces to import from, so that if there is a user-defined `user::if` then it is chosen in preference to `std::if`, if the current file spells it simply as `if`.
> **Comments:**
> **username_5** (2023-08-21): If you shadow `if` in your local package, you have to write `cl:if` throughout to access the "real" `if` form.  
---
### Answer by username_14 on 2023-05-23. Score: 5
Smalltalk just doesn’t care. `true` and `false` are just global variables. This has the advantage that it makes the interpreter simpler in some ways, but it also means that you can break a lot of things by just saying `true become:false.`
> **Comments:**
> **username_1** (2023-05-23): You can do the same in Javascript and many other languages, as stated in the question with the `open` example  
> **username_14** (2023-05-23): Overwriting built-in functions is rather different than overwriting `true` and `false`, though.  
> **username_1** (2023-05-23): Well built in functions are just global constants just like true and false are  
> **username_14** (2023-05-24): Smalltalk doesn’t even have “if” and “else” keywords, instead its booleans just have `ifTrue:` and `ifFalse:` methods. It’s often said that the only keywords in Smalltalk are self, super, true, false, nil, and thisContext.  
---
### Answer by username_15 on 2023-06-01. Score: 4
Put a dot in the keyword.
This is an idea from my language that requires keywords to have fully-qualified package names.
In my language, users can define their own keywords, which are then referred to in the same way items in external packages are: the package name, dot, then keyword.
This has a side effect that I can put keywords in the standard library in subpackages in the standard library, and those keywords will not collide with variables.
For example, say I had a print keyword like Python 2. I could put it in the io subpackage, and then I could do this:
import io;

io.print "stuff";

and the user could still use print as a variable name.
You can do this even in a language without such things, though. Just make the keyword io.print instead of just print.
The key point is that the keyword doesn't have to follow the same rules as an identifier because it's special. You can put whatever characters you want in it, including characters that don't belong in identifiers.
> **Comments:**
> **username_16** (2023-06-01): ECMAScript too has this, but when defining an item you may need brackets there. In my ECMAScript-based language I supported an escaped identifier token for allowing defining items instead of using brackets.  
> **username_17** (2023-07-21): In this example, the keyword `import` doesn't contain a dot.  
> **username_15** (2023-07-21): @tobyink keywords don't *have* to contain dots. They just can.  
> **username_17** (2023-07-24): @GavinD.Howard but if variables can be dotless and keywords can be dotless, they can still collide.  
> **username_15** (2023-07-25): @tobyink yes, but there's always a set of keywords that people avoid anyway. I meant my answer more in the context of "how do I add keywords when I have to be backwards compatible?"  
---
### Answer by username_7 on 2023-08-20. Score: 4
C# escapes keywords with `@`:

> Keywords are predefined, reserved identifiers that have special meanings to the compiler. They can't be used as identifiers in your program unless they include `@` as a prefix. For example, `@if` is a valid identifier, but `if` isn't because `if` is a keyword.

Documentation: <https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/>
---
### Answer by username_18 on 2023-08-29. Score: 4
What options do we have (to tell apart keywords and programmer-specified names)?

[Well this is a rather open-ended ended question and there are a few answers already, but here are some ideas I didn't see mentioned.]
You could remove all ambiguity between the two by making them have different naming restrictions.
For example, requiring capitalization in one but not the other. E.g. if names that start with an uppercase letter were reserved for keywords, you could have something like this, where if is a regular variable and For and If are the usual compound constructs:
For if in interfaces:
    If if = mainInterface: 
        ...

Of course reserving names with uppercase initial letters would prevent the CamelCase naming style, but would still allow camelCase with a lower case initial character, and snake_case. Names starting with acronyms and the convention of writing some constants in all uppercase might be a problem though.
Having to hit shift when writing keywords might be an annoyance for some, but I think it's somewhat comparable to typing long variables with upper and lower case letters. Both can be alleviated with a smart editor, since in most cases it's likely that e.g. a programmer writing the C-like if ( a == b ) means it as the start of a conditional structure, and not a function call, even if the keyword was really If.
Well at least as long as a function called if was not defined, anyway, but there are always limits to automatic correction.

As a more extreme variant, you could make every user-defined name carry some sort of a type identifier. The $ / @ / % sigils in variable names in Perl would be something like this, but you'd need to extend it to e.g. function names too.
E.g. with variables marked with a $, functions marked with a &, and the keyword unadorned, this should be technically unambiguous:
if &if($if):
    ...

Or do that the other way around, by having keywords contain some special character:
!if foo(if):
    ...

Even though some languages get away with mandatory sigils with variables, I expect this would be perceived as unnecessarily ugly by a few programmers. Also, there's more typing effort in that special characters are usually a bit harder to key in than letters regardless of case, and sometimes outright annoying in many keyboard layouts. E.g. Northern European keymaps have [ at AltGr+8, and even Shift-1 for ! requires reaching a bit farther than Shift-i for I.
---
### Answer by username_7 on 2023-08-21. Score: 2
var
In almost all cases you list, the problem arises when using a storage name (variable) colliding with some previously declared entity, variable or not.
This can easily be avoided with explicit declaring any expected local storage name before utilization. In other words, declaring/reserving local variable names:
# Works. Have priority for anything in this scope
# "var" as contextual keyword where variable declaration is possible,

var False = ''
var var = False
open(var)

# Unrestricted MRO/global mutating
# Define a variable OR change something defined... where?

open = 'hey'

Syntax option for alien, anything goes identifiers
Some languages use @ to explicitly define a user identifier (not only variables) that does not collide with keywords.
Taking inspiration from that, you could define an explicit syntax for all things "this is an identifier, it does not collide with anything" in language. The objective is not being convenient, but making it possible to interop with any external contexts.
Something like:
var csv = CsvReader.Parse( text )
var name = csv.@'Column name with \0 and spaces at end '
---
