<p>Almost every programming language requires strings (or <code>char*</code> or equivelent) to be marked with quotes. Few languages allow other delimiters, many languages allow single and double quotes.</p>
<p>Why is it that we even need delimiters to mark strings? What's wrong with code like this?</p>
<pre><code>name = I do not want to give my name
</code></pre>
<p>As I see it, there is one primary problem - using one variable <code>name = safwan</code> might cause confusion as to whether <code>safwan</code> is a variable or a word. However, a language could enforce quotes in this case alone. For a similar situation, <code>{hey: 9}</code> is valid JS, but if you wanted a key like <code>hey-foo</code>, you'd have to say <code>{&quot;hey-foo&quot;: 9}</code>. No quotes except when it's necessary in key definitions - why couldn't that be extended to all strings in general? Another possible area of problem might be concatenation, but concatenating two string literals is highly unusual, after all, so <code>hello</code> and <code>world</code> in <code>hello + world</code> might be assumed to be variables instead of strings.</p>
<p>It admittedly will cause a few problems, but I'm wondering why it's so rare (if it's ever occurred). It would not be the first widespread programming concept that's been questioned. Multiple languages have rebelled against the parenthesis around function calls phenomenon. If Python's <code>print(&quot;Hello World&quot;)</code> is pretty to a C programmer, Ruby has <code>print &quot;Hello World&quot;</code> - even better.</p>
<p>Why not <code>print(Hello World)</code>?</p>

<syntax><strings>
Why do programming languages use delimiters (quotes) for strings?
CC BY-SA 4.0
2023-08-28T19:07:09.633Z
Arguably regex has this feature, as well as other similar languages that require explicit escaping to mark keywords and variables
mousetail 'he-him'
CC BY-SA 4.0
2023-08-29T09:48:37.650Z
`printf so, the result is %d, 10`. Good luck!
jcaron
CC BY-SA 4.0
2023-08-29T09:54:11.157Z
@jcron Commas are definitely an issue ;)
Safwan Samsudeen
CC BY-SA 4.0
2023-08-29T13:14:41.237Z
In some languages you can omit dots and parentheses from function calls. `val y = x filter odd map square reduce multiply` is perfectly valid syntax in Scala.
Wombatz
CC BY-SA 4.0
2023-08-29T15:25:33.373Z
`print(hello); string hello = world; print(hello)`
Ray
CC BY-SA 4.0
2023-08-29T15:38:33.780Z
While we're at it, why don't programming languages have automatic concatenation of variables representing strings? `I = wow; do = this; not = is; want = a; to = confusing; give = line; my = of; name = code;` Now we can write the lovely: `I do not want to give my name == wow this is a confusing line of code`
Luke Sawczak
CC BY-SA 4.0
2023-08-29T17:13:52.627Z
@LukeSawczak It'd either make the grammar highly context-sensitive, or would require that string variables be a fundamentally different token than every other identifier, both of which make things harder for the compiler.
Ray
CC BY-SA 4.0
2023-08-30T11:55:09.363Z
Seems related to why variable-identifiers can't be numbers (e.g., no `string 2 = "Hello, world!";`) since languages could have numbers as variable-identifiers if they didn't have bare-numerics.  For example, `int 1 = "2";`.
Nat
CC BY-SA 4.0
2023-08-30T15:21:56.960Z
Your example is using "= " and newline as it's string delimiters.
RBarryYoung
CC BY-SA 4.0
2023-08-30T18:42:48.933Z
@RBarryYoung It's unclear whether the the string should be "I do not want to give my name" or " I do not want to give my name" (leading space included) without knowing English
Calvin Li
CC BY-SA 4.0
2023-08-30T22:21:19.570Z
What if the string that you want to assign to a variable happens to be a valid language construction? E.g. you want variable `s` to contain the actual string "`foo(x)`"; if you write `s = foo(x)` wouldn't that just evaluate the function? How would you distinguish between such cases?
printf
CC BY-SA 4.0
2023-08-31T01:25:14.797Z
So to answer all of these comments: as I've mentioned, problematic cases should have quotes, similar to how JS object keys work, if you've used JS.
Safwan Samsudeen
CC BY-SA 4.0
2023-08-31T03:09:23.067Z
Even in the simplest possible case, where the string is a single word, what if that word is already an identifier or a variable? Suppose you have `s = Hello`. But what if there actually is a variable called `Hello`? Suppose you have `Hello = "Good bye"` and later `s = Hello`. Do you want `s` to contain the string "Hello" or the string "Good bye" (copied from the variable `Hello`)? A string can contain anything, can be any length; and delimiters like `"` are the simplest way to indicate the beginning and the end of the string.
printf
CC BY-SA 4.0
2023-08-31T12:32:14.523Z
@CalvinLi Formally, I completely agree, but informally I concluded that the OP's intent was not to include the leading space.
RBarryYoung
CC BY-SA 4.0
2023-08-31T14:24:57.697Z
do you know about https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction
Agnishom Chattopadhyay
CC BY-SA 4.0
2023-09-08T04:21:52.000Z
Felienne Hermans’ Hedy doesn’t require them in the most basic mode, because a kid (and, well, every other beginner) often has difficulty with the finicky clerical issues of learning to program, like the correct placement of quotes, and avoiding the need at first is helpful for teaching.
Jon Purdy
CC BY-SA 4.0
2023-09-09T08:54:49.023Z
@JonPurdy thanks for that! Atleast _one_ language exists like that.
Safwan Samsudeen
<p><strong>Bare words make the language irregular and harder to maintain</strong></p>
<p>It will be almost impossible to generate an abstract syntax tree from the source code alone, as it may be necessary the run state to determine if almost every <code>/[A-Za-z0-9_]/</code> in code is an identifier or a bare word.</p>
<p>You can think of this as an extreme example of <a href="https://en.wikipedia.org/wiki/Lexer_hack" rel="noreferrer">lexer hack</a>, and may generate exponential performance problems in big projects, <em>even</em> if you do not use the resource, as every identifier must be checked anyways.</p>
<p>Say, <code>print(Hello World)</code> is:</p>
<ul>
<li><code>(call &quot;print&quot; (arg (var Hello) (var World) )</code></li>
<li><code>(call &quot;print&quot; (arg (str &quot;Hello&quot;) (var World) )</code></li>
<li><code>(call &quot;print&quot; (arg (var Hello) (str &quot;World&quot;) )</code></li>
<li><code>(call &quot;print&quot; (arg (str &quot;Hello World&quot;) )</code></li>
</ul>
<p>Bare words make code easy to write, but harder to understand or reason. In other words, the code will be very hard to debug or change.</p>
<p><strong>Every time you change an identifier <em>or</em> a string, will need to verify <em>all identifiers</em> and <em>all strings</em> in code scope, because any string or identifier naming change may impact both of these things.</strong></p>
<pre><code>// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...

// The only way to determine if
// &quot;Hello&quot; here is a string
// OR is a identifier is to
// to read AND interpret ALL
// code above this line

print(Hello)
</code></pre>

CC BY-SA 4.0
2023-08-28T14:21:41.250Z
2023-08-28T14:29:08.323Z
2023-08-28T14:29:08.323Z
André L F S Bacci
CC BY-SA 4.0
2023-08-28T23:37:00.337Z
To add to what you said, consider that, according to thought leaders like Martin Fowler, we write code for humans, not for computers.  The problem of strings without quotes goes beyond what we can or cannot teach the compiler to do.  Like you said, changing any string requires a review of every single word of code and strings.
Dale
CC BY-SA 4.0
2023-08-29T00:38:23.913Z
Thanks for answering! This is definitely an important point.
Safwan Samsudeen
<p>The feature you're asking about is known as <a href="https://en.wiktionary.org/wiki/bareword" rel="noreferrer">barewords</a>, and they're common in markup languages such as HTML and (La)TeX, where the &quot;strings&quot; indicate text to be displayed, and data languages such as YAML and CSV, where there are no identifiers to confuse them with.</p>
<p>Perl and most shells also support barewords, since every use of a variable has to be prefixed with a &quot;sigil&quot; (i.e. <code>$foo</code>) in those languages. Ruby and JS can support barewords -- by <a href="https://www.destroyallsoftware.com/talks/wat" rel="noreferrer">defining a particular <code>method_missing</code></a> or <a href="https://chat.stackexchange.com/transcript/message/64262831#64262831">using <code>with</code> + a Proxy</a> respectively -- but this is rare in practice, since <strong>it makes it difficult to tell apart unquoted strings from local variables, and mistyping a variable name won't be an error.</strong> In JavaScript specifically, barewords are common in <a href="https://react.dev/learn/writing-markup-with-jsx" rel="noreferrer">React's JSX syntax</a>, which is meant to look as similar to HTML as possible, and because variables can only be used inside brace expansion.</p>

CC BY-SA 4.0
2023-08-28T12:43:29.733Z
2023-08-28T12:43:29.733Z
Bbrk24
CC BY-SA 4.0
2023-08-28T14:41:51.380Z
I wouldn't say barewords are common in markup languages. There it's just a reversal of what you quote: instead of quoting the strings, you quote the rest.
G. Sliepen
CC BY-SA 4.0
2023-08-28T20:13:00.723Z
You can use barewords in python too: https://stackoverflow.com/questions/29492895/bare-words-new-keywords-in-python/29492897#29492897
mousetail 'he-him'
CC BY-SA 4.0
2023-08-31T14:26:39.523Z
LaTeX comes to mind
Agnishom Chattopadhyay
CC BY-SA 4.0
2023-08-31T22:48:14.567Z
“YAML, where there are no identifiers to confuse them with” Norway would like to have a word with you…
xigoi
<p>Your question can be very simply answered by another two questions. As you wrote that, did you want a single space at the start of your string or not? And were there any spaces at the end or not?</p>
<p>In general, whitespace is useful for making code more readable. In most human languages, we put spaces between words, so doing the same in code is natural. You did it yourself there without even thinking about it - even in a question where you're asking about implicit string parsing without delimiters. Should your hypothetical language use the &quot;you get what you ask for&quot; principle and give you an extra space, then? And if not, how do you get an initial space if you <em>do</em> want one?</p>
<p>And then there's whitespace at the end. Unless you turn on glyphs for non-printing characters in your text editor, a reader/reviewer simply won't know whether there are extra characters there or not. The least worst consequence might be text not being displayed how you want it. The worst might be an array overflow or a runtime assert.</p>
<p>You also have an incorrect belief that using text delimiters such as quotes is somehow hard or unnatural for people to use. Every written European language uses some form of delimiters for representing speech though - not necessarily quote marks, but <em>something</em>. If you're literate enough to read and write code, then you can already read and write at least your own native language - and therefore you are already fully familiar with this convention. I can't say whether this is true for other languages around the world, but it certainly is true for every European language. Your proposal therefore could never benefit even one individual in the entire Western world in the entire past and future of code writing.</p>
<p>So. Provable parsing issues. Provable lack of any benefit to any user. Yep, we're not going there. ;-)</p>

CC BY-SA 4.0
2023-08-29T19:35:57.710Z
2023-08-30T16:57:22.023Z
2023-08-30T16:57:22.023Z
Graham
CC BY-SA 4.0
2023-08-30T16:00:11.567Z
"Every written European language uses these for representing speech" This is being nitpicky, but a significant chunk of European languages (maybe most of them?) use guillemets for this purpose, not English quotation marks. See https://en.wikipedia.org/wiki/Guillemet#As_quotation_marks for examples. :P Edit: Though I realize in hindsight that you might have just meant that they use text delimiters _at all;_ my mistake if so!
Idran
CC BY-SA 4.0
2023-08-30T16:56:13.057Z
@JustinHilyard Yes, I meant that they all use some form of delimiters. I can make that clearer.
Graham
CC BY-SA 4.0
2023-08-30T17:23:14.997Z
I think this is overstating the case against unquoted string literals; consider for example PHP, which used to have them, so that it was possible to write e.g. `$_GET[foo]` instead of `$_GET['foo']`. The former is a bit easier to read, and a bit easier to type. To be clear, I think that's not enough for it to be worth having the feature in the language, but it answers your questions: whitespace before and after should be ignored, because the keys in a dictionary will very rarely contain whitespace at the start or end. If there was no benefit then people wouldn't have written PHP this way.
kaya3
CC BY-SA 4.0
2023-08-30T22:00:11.293Z
@kaya3 Really it shows how PHP wasn't actually designed. The original author said himself that he had no idea what he was doing, never designed it, and never even intended it to become a full language. PHP is a great example of what you get when you *don't* do a proper design and think about stuff like that.
Graham
CC BY-SA 4.0
2023-08-30T22:20:25.993Z
I didn't claim that PHP is well-designed. What I said is that PHP had this feature and people who wrote in PHP found it beneficial for this use-case. To say there is a "lack of any benefit to any user" is hyperbole.
kaya3
<p>There are conflicting requirements: I want it to be easy to create a string literal in the source code containing whatever character sequence I want it to contain. I want it to be easy to see a string literal in the source code and figure out which character sequence it represents. And I want it to be hard to make stupid mistakes. What is not an argument for a feature is &quot;I can do it&quot;.</p>
<p>Being able to write a sequence of ASCII letters to indicate a string is nice, but then what about other ASCII characters? Other Unicode letters and other Unicode characters? ASCII letters that match keywords in the language? That's where the proposal fails IMO.</p>
<p>Many languages start with a simple rule: A string literal is any sequence of characters enclosed between double quotes. Then someone realises that you can't create a string literal representing a double quote. Three methods are used that are more or less helpful: <code>&quot;&quot;</code> in a string literal doesn't indicate the end of one string literal followed immediately by another one, but means a double quote becomes part of the string literal. Or we use escape sequences, for example <code>\&quot;</code> means a double quote character, <code>\\</code> means a single backslash character (otherwise we can't include a backslash character in a string literal) and some more. Or we state that a string literal may be enclosed in single quotes instead, which is often a simple solution avoiding escape sequences.</p>
<p>Swift (and others I believe) has multi-line string literals. An example:</p>
<pre><code>let s = &quot;&quot;&quot;
This is a string literal
containing a line break
&quot;&quot;&quot;
</code></pre>
<p>Here the string literal can contain anything except a <code>&quot;&quot;&quot;</code> sequence, which makes it quite useful to create help text to be displayed on the screen, or source code and so on. It's meaning is clear because the <code>&quot;&quot;&quot;</code> at the start and end stand out.</p>
<p>And C has the feature that what looks like two consecutive string literals with nothing but white space in between is merged by the compiler into a single string literal. For example <code>&quot;Hello&quot; &quot;, &quot; &quot;world&quot;</code> and <code>&quot;Hello, world&quot;</code> are compiled to exactly the same string literal. This would be a problem with bare words because now two words are a single string literal with no space between them.</p>

CC BY-SA 4.0
2023-08-28T22:45:14.543Z
2023-08-28T22:54:18.857Z
2023-08-28T22:54:18.857Z
gnasher729
<p>In addition to all of the other reasons, consider that when computer languages were first created, computers didn't have the CPU power, memory, and other resources for doing complex code interpretations that a modern, AI-based compiler or interpreter might have.</p>
<p>It might (or might not) be possible to create a reliable interpreter for barewords today, and it might (or might not) have been theoretically possible 80 years ago but it is sure there were other priorities for CPU cycles for most of those 80 years.</p>
<p>Now it is so embedded into our minds and practices, just as it is in our spoken languages, that the cost of keeping it that way is far, far, less than the cost of trying to change it.</p>
<p>Consider that Abraham Lincoln once said four score and seven years ago and computer memory and power has increased by a power of thousands.</p>
<p>Bet you didn't even know that Mr. Lincoln knew about computers, did you?</p>

CC BY-SA 4.0
2023-08-28T21:06:21.610Z
2023-08-28T21:06:21.610Z
Dale
CC BY-SA 4.0
2023-08-28T21:08:15.053Z
What modern compilers or interpreters for programming languages are AI-based?
kaya3
CC BY-SA 4.0
2023-08-28T21:15:52.967Z
None that I know of but the reference is about the modern computer capabilities that might (or might not) be of use in interpreting barewords.  Machine learning and AI might be the only way to accomplish barewords interpretation reliably because there would be a seemingly infinite number of scenarios and speech patterns to interpret.  So when I spoke about modern computer compilers and interpreters, in a hypothetical scenario, I used a hypothetical model.  I'm sorry that the reference to AI is all that you got out of my answer.
Dale
CC BY-SA 4.0
2023-08-28T21:40:57.873Z
Well, most of the rest of your answer is unsupported too, but I figured it would be easier to only ask you about one thing. If you only meant this to be speculation then I suggest you edit to remove it. Is there any reason you think supporting barewords would require enormous computational resources, besides speculation? What do speech patterns have to do with it?
kaya3
CC BY-SA 4.0
2023-08-28T22:35:27.857Z
Are you suggesting that analyzing every potential bit of text, every statement intended for human consumption that's built into a computer program, across every language, both current and ancient, would NOT take an enormous amount of compute power to review and separate from words having the purpose of communicating intentions from a human to the computer itself?
Dale
CC BY-SA 4.0
2023-08-28T22:40:10.393Z
I am not suggesting that at all, and why would that be necessary to support barewords in a programming language's syntax? Note that some existing languages *do* support them (see other answers for details). I think you have seriously misunderstood the question.
kaya3
CC BY-SA 4.0
2023-08-28T22:41:49.253Z
Speech patterns are very critical to doing barewords successfully and reliably.  The goal of most computer programs is to communicate something to a  human being in support of some business decision or objective.  When strings of speech are intermingled with strings of other data and instructions to the computer, itself, how do you differentiate them unless you can isolate the human speech or messages, in every single possible language?  For example, consider my quote from Abraham Lincoln about his view on computer power.
Dale
CC BY-SA 4.0
2023-08-28T22:46:35.593Z
As another pointed out, there are delimiters in those other languages: a space at the beginning and an EOL at the end.  And they don't truly support barewords and at least one mentioned stopped supporting barewords - because it can't truly be done reliably and completely - at least  not without huge computing power and maching learning/AI.  A  human can never write enough code to parse out every possible human language phrase from computer instruction.  I'm not going to continue to argue; I've offered my reply and comments and they can be voted on. Peace out.
Dale
CC BY-SA 4.0
2023-08-28T22:50:09.867Z
Unix shell has unquoted string values and dates back more than fifty years; I don't see how this CPU-power argument holds water and it would help to [edit] the answer to provide some more backing to the claims it makes.
Michael Homer
CC BY-SA 4.0
2023-08-28T22:51:27.420Z
You differentiate them either in the language's grammar, by allowing them in certain places where the parser knows that bare identifiers are string literals; or otherwise you differentiate them after parsing by finding whether the identifier corresponds with a named declaration and, if it doesn't, treating it as a string literal. Or both. Those are completely reliable ways, unlike anything based on a probabilistic AI language model with no formally specified behaviour. It sounds like you have taken the question to mean the compiler must have human intelligence, but that is not what it's about.
kaya3
CC BY-SA 4.0
2023-08-28T23:03:04.667Z
@MichaelHomer, Unix has unquoted strings but it doesn't have undelimited strings. Try this command in Linux or Unix:  mkdir "test directory" and tell me how it works out for you - oh, you can't comprehend my instructions without delimiters or marks so I added the quotes.  Don't add the quotes when you run the command.
Dale
CC BY-SA 4.0
2023-08-28T23:08:44.840Z
I didn't say the compiler needed human intelligence.  AI is not human intelligence.  That seems to be a mistake on your part.  AI is built on evaluating typically huge datasets and learning patterns from that data.  That doesn't make AI human or even human-like.  It simply means that it can learn in advance from previous knowledge versus doing a few hundred trillion regex calculations in answer to a single command such as print first name.  ML comes in to basically add to that knowledge from real time or new input.
Dale
CC BY-SA 4.0
2023-08-28T23:11:01.530Z
The OP's question can never be answered absolutely and every answer is, in the end, speculation.  If anyone thinks that you can consistently and reliably, in all cases, mix code with strings meant for human consumption, without huge computing power, tell how that would happen and where it's happening today.  And don't forget that even the code we write is only intended for human readers, as well.  Computers don't understand C or JavaScript.  Computers don't understand assembly.  They understand binary.
Dale
CC BY-SA 4.0
2023-08-28T23:24:34.210Z
@kaya3, differentiating by patterns in the programming language is most certainly not a reliable way to do it.  First off, that requires telling every speaker of 7139 spoken languages that they can't say certain things in certain ways because my compiler will get confused.  And what if I am writing a code review program?  My program requires the ability to offer the programmer suggestions how to properly accomplish something they violated.  Now my data and my output look exactly like my syntax.  The compiler must, in every case, properly tell the difference.
Dale
CC BY-SA 4.0
2023-08-29T01:38:27.830Z
Forgive me, but I don't get the Lincoln reference. How do computers tie in with the Gettysburg Address?
Safwan Samsudeen
CC BY-SA 4.0
2023-08-29T06:28:13.407Z
*"Consider that Abraham Lincoln once said four score and seven years ago and computer memory and power has increased by a power of thousands."* - a "Chewbacca defence" if I ever saw one!
Steve
CC BY-SA 4.0
2023-08-29T14:34:40.443Z
@kaya3 I'm not sure if I understood the OP correctly, but if I did, the idea is a compiler that can automatically distinguish bare words from variable names: If you write `myVariable = Hello`, the compiler automatically "knows" if the string constant `"Hello"` or a variable named `Hello` is meant. *Maybe* an AI-based compiler would be able to do this (I doubt about that).
Martin Rosenau
CC BY-SA 4.0
2023-08-29T21:18:08.780Z
@SafwanSamsudeen, computers don't tie into the Gettysburg Address.  The point was two separate ideas but without quotes they don't appear as separate ideas.  Also see my example of mkdir test directory.  This whole idea got blown up because someone argued whether it took a lot of computer resources to do barewords, arguing minutiae rather than the point that early computers certainly didn't have the power to sort out such things and the pattern of using quotes was established early and no one wants to put in the effort to change it now.
Dale
CC BY-SA 4.0
2023-08-30T10:50:55.780Z
@Dale what makes you think that early computers couldn't have handled that computation? You've repeatedly _asserted_ it, but you haven't _justified_ it at any point.
Brondahl
CC BY-SA 4.0
2023-08-30T12:00:33.763Z
@Dale I appreciate your effort to answer. Next time, I recommend you back it up with more references/facts and a clearer argument (the Lincoln ref was definitely confusing). All the same, thanks! I see you're a new contributor, and I hope this experience doesn't push you off contributing. Best of luck!
Safwan Samsudeen
CC BY-SA 4.0
2023-09-10T13:52:56.873Z
This answer is missing the foundational contributions of Gödel and Quine. Quotation is akin to a modality and requires some sort of marker in formal logic.
Corbin
<p>The feature you're asking about is called &quot;<a href="https://en.wiktionary.org/wiki/bareword" rel="nofollow noreferrer">barewords</a>&quot; or &quot;bare words&quot;, which means that identifiers in some contexts are taken to be string literals, and possibly also that consecutive identifiers are taken to be joined as strings with spaces between. However, some other languages or communities use the term &quot;bareword&quot; to mean other things (e.g. function invocations without parentheses in <a href="https://notes.max.engineer/ruby-barewords-are-insidious" rel="nofollow noreferrer">Ruby</a> and <a href="https://iamvery.com/2016/12/05/elixir-deprecation-of-barewords.html" rel="nofollow noreferrer">Elixir</a>), so be aware of that when searching for information about this topic.</p>
<p>Before discussing why languages don't have this feature, it's worth noting that some actually do, or did:</p>
<ul>
<li><a href="https://perlmaven.com/barewords-in-perl" rel="nofollow noreferrer">Perl</a> is most known for having them, and the term &quot;bareword&quot; appears to come from the Perl community. Apparently they don't exist in Raku (formerly known as Perl 6).</li>
<li>PHP used to have them, but they were <a href="https://wiki.php.net/rfc/deprecate-bareword-strings" rel="nofollow noreferrer">deprecated in version 7.2</a>.</li>
<li>The esolang <a href="https://github.com/sampersand/squire" rel="nofollow noreferrer">Squire</a> apparently has them, and uses <a href="https://en.wikipedia.org/wiki/Fraktur" rel="nofollow noreferrer">Fraktur</a> Unicode letters to disambiguate between identifiers and barewords.</li>
</ul>
<p>Some other languages including <a href="https://stackoverflow.com/q/18652859/12299000">Lua</a>, <a href="https://www.destroyallsoftware.com/talks/wat" rel="nofollow noreferrer">Ruby</a>, <a href="https://stackoverflow.com/q/29492895/12299000">Python</a> and <a href="https://github.com/pokemonish/bare_words_js" rel="nofollow noreferrer">Javascript</a> don't have barewords as a feature, but can be given them in user code by combining other language features in unintended and hacky ways.</p>
<p><a href="https://langdev.stackexchange.com/a/2824/89">Bbrk24's answer</a> notes also that markup languages and data languages may have barewords, but very different considerations apply to such languages as to traditional programming languages.</p>
<hr />
<p>So why not have them in a programming language? There are so many reasons they're a bad idea, but there are two main reasons:</p>
<ul>
<li>They can turn spelling mistakes from simple errors that get noticed immediately, into bugs which don't happen until runtime ─ and typically, not recoverable ones. If a misspelled identifier has some meaning despite being undeclared, then a static checker or linter can't reject it without banning all use of barewords anyway. Then at runtime, either a string value is used where some other type was expected, or the wrong string value is used.</li>
<li>They make the meaning of an expression dependent on outside context which can easily change. If an identifier used as a bareword is later declared in some outer scope ─ either in the same codebase, as a wildcard import from a third-party library, or as a built-in in a later version of the language ─ then it's no longer a bareword and now refers to that declaration. The same isn't true for other uses of identifiers, due to <a href="https://en.wikipedia.org/wiki/Variable_shadowing" rel="nofollow noreferrer">shadowing</a>.</li>
</ul>
<p>Another reason is that it makes it harder to introduce new keywords or reserved words in the language's syntax, since those words are more likely to already appear in existing code.</p>
<p>For a more in-depth discussion of why not to have them, take a look at the <a href="https://wiki.php.net/rfc/deprecate-bareword-strings" rel="nofollow noreferrer">rationale for deprecating them in PHP</a>, or relatedly the <a href="https://github.com/elixir-lang/elixir/issues/3268" rel="nofollow noreferrer">rationale for now requiring parentheses for zero-argument function calls in Elixir</a>.</p>

CC BY-SA 4.0
2023-08-28T13:11:42.913Z
2023-09-10T11:00:33.153Z
2023-09-10T11:00:33.153Z
kaya3
CC BY-SA 4.0
2023-08-28T19:12:36.173Z
A stronger example of an existing language with unquoted strings would be shell script. Perl barewords are also somewhat complex and often *not* strings, which wasn’t the case when they were copied into PHP.
Michael Homer
CC BY-SA 4.0
2023-08-28T23:13:04.333Z
As I understand about the second point in why programming languages don't often use barewords, it's useful in the case of differentiating *var x = Null* and *var x = "Null"* - where you need a word that would be a bareword for determining that there is an uninitialized string versus a string with the text "Null".
Alexander The 1st
CC BY-SA 4.0
2023-08-29T06:24:23.027Z
I would wonder about the rationale behind _"A string on a line of its own is a valid statement, which does nothing."_ from the linked PHP RFC.
CodeCaster
CC BY-SA 4.0
2023-08-29T11:45:36.300Z
@CodeCaster The same is true in many dynamic languages. In some (e.g. Javascript `"use strict"`, or Python doc comments) statements which consist only of a string literal may nonetheless have some meaning. But mainly I think it's just because dynamic languages tend to prefer making things valid if they don't need to be invalid. Having `Expression ';'` as a production rule for statements in the grammar is also simpler than excluding some syntactical forms of expression which aren't useful as statements. I suspect there is more to say on the topic, so perhaps you should ask it as a question.
kaya3
CC BY-SA 4.0
2023-08-29T17:28:36.313Z
@CodeCaster, I think it's also true for e.g. C, exactly because a string (or a constant number) is a valid expression, the same as any function call, and you do want to allow statements with just a function call. It follows from the simple way of writing the grammar, though compilers do tend to warn of it.
ilkkachu
CC BY-SA 4.0
2023-08-30T08:38:29.823Z
Another language that uses Barewords (sort of) is REXX. In REXX a variable's value defaults to its name in upper case.
theblitz
CC BY-SA 4.0
2023-08-30T23:26:41.173Z
From the "Good uses of barewords" section of your perlmaven.com link, it shows a bareword for a hash index (e.g.) `$myhash{foo} = 123;`. Since `perl` doesn't have [true] struct/class support, this was a way to get them: `$ptr = {}; $ptr->{foo} = 123;` with a syntax similar to C doing `struct xxx { int foo; }; ... ptr->foo = 123;`. Doing `$ptr->{"foo"}` gets old fast (trust me, I know because I've been using the barewords for this for 3 decades). With `raku`, you have _real_ struct/class support, and can do: `%ptr.foo = 123;`
Craig Estey
CC BY-SA 4.0
2023-08-31T15:58:20.883Z
The second reason you listed about why we dont' have them is very much why I, as a programmer, wouldn't want them - I don't ever want to be confused myself about if something is an identifier or a string, and I don't want to have to worry about if I'm breaking some code by using a term from a bare string as a variable name at a later time.
TKoL
CC BY-SA 4.0
2023-08-31T16:56:59.713Z
FYI: Lua does allow barewords in defining the contents of new tables.  I.e., ```tbl = { first = one, second = two }```
Jeffiekins
CC BY-SA 4.0
2023-09-07T10:52:09.417Z
FWIW, Perl really doesn't recommend using barewords anymore either. They're generally viewed as a bad way to write.
oldtechaa
# Why do programming languages use delimiters (quotes) for strings?
Posted by: username_0 on 2023-08-28
Almost every programming language requires strings (or char* or equivelent) to be marked with quotes. Few languages allow other delimiters, many languages allow single and double quotes.
Why is it that we even need delimiters to mark strings? What's wrong with code like this?
name = I do not want to give my name

As I see it, there is one primary problem - using one variable name = safwan might cause confusion as to whether safwan is a variable or a word. However, a language could enforce quotes in this case alone. For a similar situation, {hey: 9} is valid JS, but if you wanted a key like hey-foo, you'd have to say {"hey-foo": 9}. No quotes except when it's necessary in key definitions - why couldn't that be extended to all strings in general? Another possible area of problem might be concatenation, but concatenating two string literals is highly unusual, after all, so hello and world in hello + world might be assumed to be variables instead of strings.
It admittedly will cause a few problems, but I'm wondering why it's so rare (if it's ever occurred). It would not be the first widespread programming concept that's been questioned. Multiple languages have rebelled against the parenthesis around function calls phenomenon. If Python's print("Hello World") is pretty to a C programmer, Ruby has print "Hello World" - even better.
Why not print(Hello World)?
**Tags:** syntax strings
> **Comments:**
> **username_1**: Arguably regex has this feature, as well as other similar languages that require explicit escaping to mark keywords and variables  
> **username_2**: `printf so, the result is %d, 10`. Good luck!  
> **username_0**: @jcron Commas are definitely an issue ;)  
> **username_3**: In some languages you can omit dots and parentheses from function calls. `val y = x filter odd map square reduce multiply` is perfectly valid syntax in Scala.  
> **username_4**: `print(hello); string hello = world; print(hello)`  
> **username_5**: While we're at it, why don't programming languages have automatic concatenation of variables representing strings? `I = wow; do = this; not = is; want = a; to = confusing; give = line; my = of; name = code;` Now we can write the lovely: `I do not want to give my name == wow this is a confusing line of code`  
> **username_4**: @LukeSawczak It'd either make the grammar highly context-sensitive, or would require that string variables be a fundamentally different token than every other identifier, both of which make things harder for the compiler.  
> **username_6**: Seems related to why variable-identifiers can't be numbers (e.g., no `string 2 = "Hello, world!";`) since languages could have numbers as variable-identifiers if they didn't have bare-numerics.  For example, `int 1 = "2";`.  
> **username_7**: Your example is using "= " and newline as it's string delimiters.  
> **username_8**: @RBarryYoung It's unclear whether the the string should be "I do not want to give my name" or " I do not want to give my name" (leading space included) without knowing English  
> **username_9**: What if the string that you want to assign to a variable happens to be a valid language construction? E.g. you want variable `s` to contain the actual string "`foo(x)`"; if you write `s = foo(x)` wouldn't that just evaluate the function? How would you distinguish between such cases?  
> **username_0**: So to answer all of these comments: as I've mentioned, problematic cases should have quotes, similar to how JS object keys work, if you've used JS.  
> **username_9**: Even in the simplest possible case, where the string is a single word, what if that word is already an identifier or a variable? Suppose you have `s = Hello`. But what if there actually is a variable called `Hello`? Suppose you have `Hello = "Good bye"` and later `s = Hello`. Do you want `s` to contain the string "Hello" or the string "Good bye" (copied from the variable `Hello`)? A string can contain anything, can be any length; and delimiters like `"` are the simplest way to indicate the beginning and the end of the string.  
> **username_7**: @CalvinLi Formally, I completely agree, but informally I concluded that the OP's intent was not to include the leading space.  
> **username_10**: do you know about https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction  
> **username_11**: Felienne Hermans’ Hedy doesn’t require them in the most basic mode, because a kid (and, well, every other beginner) often has difficulty with the finicky clerical issues of learning to program, like the correct placement of quotes, and avoiding the need at first is helpful for teaching.  
> **username_0**: @JonPurdy thanks for that! Atleast _one_ language exists like that.  
---
## 6 answers
### Answer by username_19 on 2023-08-28. Score: 51 | Accepted answer
The feature you're asking about is called "[barewords](https://en.wiktionary.org/wiki/bareword)" or "bare words", which means that identifiers in some contexts are taken to be string literals, and possibly also that consecutive identifiers are taken to be joined as strings with spaces between. However, some other languages or communities use the term "bareword" to mean other things (e.g. function invocations without parentheses in [Ruby](https://notes.max.engineer/ruby-barewords-are-insidious) and [Elixir](https://iamvery.com/2016/12/05/elixir-deprecation-of-barewords.html)), so be aware of that when searching for information about this topic.

Before discussing why languages don't have this feature, it's worth noting that some actually do, or did:

* [Perl](https://perlmaven.com/barewords-in-perl) is most known for having them, and the term "bareword" appears to come from the Perl community. Apparently they don't exist in Raku (formerly known as Perl 6).
* PHP used to have them, but they were [deprecated in version 7.2](https://wiki.php.net/rfc/deprecate-bareword-strings).
* The esolang [Squire](https://github.com/sampersand/squire) apparently has them, and uses [Fraktur](https://en.wikipedia.org/wiki/Fraktur) Unicode letters to disambiguate between identifiers and barewords.

Some other languages including [Lua](https://stackoverflow.com/q/18652859/12299000), [Ruby](https://www.destroyallsoftware.com/talks/wat), [Python](https://stackoverflow.com/q/29492895/12299000) and [Javascript](https://github.com/pokemonish/bare_words_js) don't have barewords as a feature, but can be given them in user code by combining other language features in unintended and hacky ways.

[Bbrk24's answer](https://langdev.stackexchange.com/a/2824/89) notes also that markup languages and data languages may have barewords, but very different considerations apply to such languages as to traditional programming languages.

---

So why not have them in a programming language? There are so many reasons they're a bad idea, but there are two main reasons:

* They can turn spelling mistakes from simple errors that get noticed immediately, into bugs which don't happen until runtime ─ and typically, not recoverable ones. If a misspelled identifier has some meaning despite being undeclared, then a static checker or linter can't reject it without banning all use of barewords anyway. Then at runtime, either a string value is used where some other type was expected, or the wrong string value is used.
* They make the meaning of an expression dependent on outside context which can easily change. If an identifier used as a bareword is later declared in some outer scope ─ either in the same codebase, as a wildcard import from a third-party library, or as a built-in in a later version of the language ─ then it's no longer a bareword and now refers to that declaration. The same isn't true for other uses of identifiers, due to [shadowing](https://en.wikipedia.org/wiki/Variable_shadowing).

Another reason is that it makes it harder to introduce new keywords or reserved words in the language's syntax, since those words are more likely to already appear in existing code.

For a more in-depth discussion of why not to have them, take a look at the [rationale for deprecating them in PHP](https://wiki.php.net/rfc/deprecate-bareword-strings), or relatedly the [rationale for now requiring parentheses for zero-argument function calls in Elixir](https://github.com/elixir-lang/elixir/issues/3268).
> **Comments:**
> **username_21** (2023-08-28): A stronger example of an existing language with unquoted strings would be shell script. Perl barewords are also somewhat complex and often *not* strings, which wasn’t the case when they were copied into PHP.  
> **username_26** (2023-08-28): As I understand about the second point in why programming languages don't often use barewords, it's useful in the case of differentiating *var x = Null* and *var x = "Null"* - where you need a word that would be a bareword for determining that there is an uninitialized string versus a string with the text "Null".  
> **username_27** (2023-08-29): I would wonder about the rationale behind _"A string on a line of its own is a valid statement, which does nothing."_ from the linked PHP RFC.  
> **username_19** (2023-08-29): @CodeCaster The same is true in many dynamic languages. In some (e.g. Javascript `"use strict"`, or Python doc comments) statements which consist only of a string literal may nonetheless have some meaning. But mainly I think it's just because dynamic languages tend to prefer making things valid if they don't need to be invalid. Having `Expression ';'` as a production rule for statements in the grammar is also simpler than excluding some syntactical forms of expression which aren't useful as statements. I suspect there is more to say on the topic, so perhaps you should ask it as a question.  
> **username_28** (2023-08-29): @CodeCaster, I think it's also true for e.g. C, exactly because a string (or a constant number) is a valid expression, the same as any function call, and you do want to allow statements with just a function call. It follows from the simple way of writing the grammar, though compilers do tend to warn of it.  
> **username_29** (2023-08-30): Another language that uses Barewords (sort of) is REXX. In REXX a variable's value defaults to its name in upper case.  
> **username_30** (2023-08-30): From the "Good uses of barewords" section of your perlmaven.com link, it shows a bareword for a hash index (e.g.) `$myhash{foo} = 123;`. Since `perl` doesn't have [true] struct/class support, this was a way to get them: `$ptr = {}; $ptr->{foo} = 123;` with a syntax similar to C doing `struct xxx { int foo; }; ... ptr->foo = 123;`. Doing `$ptr->{"foo"}` gets old fast (trust me, I know because I've been using the barewords for this for 3 decades). With `raku`, you have _real_ struct/class support, and can do: `%ptr.foo = 123;`  
> **username_31** (2023-08-31): The second reason you listed about why we dont' have them is very much why I, as a programmer, wouldn't want them - I don't ever want to be confused myself about if something is an identifier or a string, and I don't want to have to worry about if I'm breaking some code by using a term from a bare string as a variable name at a later time.  
> **username_32** (2023-08-31): FYI: Lua does allow barewords in defining the contents of new tables.  I.e., ```tbl = { first = one, second = two }```  
> **username_33** (2023-09-07): FWIW, Perl really doesn't recommend using barewords anymore either. They're generally viewed as a bad way to write.  
---
### Answer by username_14 on 2023-08-28. Score: 15
The feature you're asking about is known as [barewords](https://en.wiktionary.org/wiki/bareword), and they're common in markup languages such as HTML and (La)TeX, where the "strings" indicate text to be displayed, and data languages such as YAML and CSV, where there are no identifiers to confuse them with.

Perl and most shells also support barewords, since every use of a variable has to be prefixed with a "sigil" (i.e. `$foo`) in those languages. Ruby and JS can support barewords -- by [defining a particular `method_missing`](https://www.destroyallsoftware.com/talks/wat) or [using `with` + a Proxy](https://chat.stackexchange.com/transcript/message/64262831#64262831) respectively -- but this is rare in practice, since **it makes it difficult to tell apart unquoted strings from local variables, and mistyping a variable name won't be an error.** In JavaScript specifically, barewords are common in [React's JSX syntax](https://react.dev/learn/writing-markup-with-jsx), which is meant to look as similar to HTML as possible, and because variables can only be used inside brace expansion.
> **Comments:**
> **username_15** (2023-08-28): I wouldn't say barewords are common in markup languages. There it's just a reversal of what you quote: instead of quoting the strings, you quote the rest.  
> **username_1** (2023-08-28): You can use barewords in python too: https://stackoverflow.com/questions/29492895/bare-words-new-keywords-in-python/29492897#29492897  
> **username_10** (2023-08-31): LaTeX comes to mind  
> **username_16** (2023-08-31): “YAML, where there are no identifiers to confuse them with” Norway would like to have a word with you…  
---
### Answer by username_12 on 2023-08-28. Score: 13
Bare words make the language irregular and harder to maintain
It will be almost impossible to generate an abstract syntax tree from the source code alone, as it may be necessary the run state to determine if almost every /[A-Za-z0-9_]/ in code is an identifier or a bare word.
You can think of this as an extreme example of lexer hack, and may generate exponential performance problems in big projects, even if you do not use the resource, as every identifier must be checked anyways.
Say, print(Hello World) is:

(call "print" (arg (var Hello) (var World) )
(call "print" (arg (str "Hello") (var World) )
(call "print" (arg (var Hello) (str "World") )
(call "print" (arg (str "Hello World") )

Bare words make code easy to write, but harder to understand or reason. In other words, the code will be very hard to debug or change.
Every time you change an identifier or a string, will need to verify all identifiers and all strings in code scope, because any string or identifier naming change may impact both of these things.
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...
// code ...

// The only way to determine if
// "Hello" here is a string
// OR is a identifier is to
// to read AND interpret ALL
// code above this line

print(Hello)
> **Comments:**
> **username_13** (2023-08-28): To add to what you said, consider that, according to thought leaders like Martin Fowler, we write code for humans, not for computers.  The problem of strings without quotes goes beyond what we can or cannot teach the compiler to do.  Like you said, changing any string requires a review of every single word of code and strings.  
> **username_0** (2023-08-29): Thanks for answering! This is definitely an important point.  
---
### Answer by username_17 on 2023-08-29. Score: 5
Your question can be very simply answered by another two questions. As you wrote that, did you want a single space at the start of your string or not? And were there any spaces at the end or not?

In general, whitespace is useful for making code more readable. In most human languages, we put spaces between words, so doing the same in code is natural. You did it yourself there without even thinking about it - even in a question where you're asking about implicit string parsing without delimiters. Should your hypothetical language use the "you get what you ask for" principle and give you an extra space, then? And if not, how do you get an initial space if you *do* want one?

And then there's whitespace at the end. Unless you turn on glyphs for non-printing characters in your text editor, a reader/reviewer simply won't know whether there are extra characters there or not. The least worst consequence might be text not being displayed how you want it. The worst might be an array overflow or a runtime assert.

You also have an incorrect belief that using text delimiters such as quotes is somehow hard or unnatural for people to use. Every written European language uses some form of delimiters for representing speech though - not necessarily quote marks, but *something*. If you're literate enough to read and write code, then you can already read and write at least your own native language - and therefore you are already fully familiar with this convention. I can't say whether this is true for other languages around the world, but it certainly is true for every European language. Your proposal therefore could never benefit even one individual in the entire Western world in the entire past and future of code writing.

So. Provable parsing issues. Provable lack of any benefit to any user. Yep, we're not going there. ;-)
> **Comments:**
> **username_18** (2023-08-30): "Every written European language uses these for representing speech" This is being nitpicky, but a significant chunk of European languages (maybe most of them?) use guillemets for this purpose, not English quotation marks. See https://en.wikipedia.org/wiki/Guillemet#As_quotation_marks for examples. :P Edit: Though I realize in hindsight that you might have just meant that they use text delimiters _at all;_ my mistake if so!  
> **username_17** (2023-08-30): @JustinHilyard Yes, I meant that they all use some form of delimiters. I can make that clearer.  
> **username_19** (2023-08-30): I think this is overstating the case against unquoted string literals; consider for example PHP, which used to have them, so that it was possible to write e.g. `$_GET[foo]` instead of `$_GET['foo']`. The former is a bit easier to read, and a bit easier to type. To be clear, I think that's not enough for it to be worth having the feature in the language, but it answers your questions: whitespace before and after should be ignored, because the keys in a dictionary will very rarely contain whitespace at the start or end. If there was no benefit then people wouldn't have written PHP this way.  
> **username_17** (2023-08-30): @kaya3 Really it shows how PHP wasn't actually designed. The original author said himself that he had no idea what he was doing, never designed it, and never even intended it to become a full language. PHP is a great example of what you get when you *don't* do a proper design and think about stuff like that.  
> **username_19** (2023-08-30): I didn't claim that PHP is well-designed. What I said is that PHP had this feature and people who wrote in PHP found it beneficial for this use-case. To say there is a "lack of any benefit to any user" is hyperbole.  
---
### Answer by username_20 on 2023-08-28. Score: 3
There are conflicting requirements: I want it to be easy to create a string literal in the source code containing whatever character sequence I want it to contain. I want it to be easy to see a string literal in the source code and figure out which character sequence it represents. And I want it to be hard to make stupid mistakes. What is not an argument for a feature is "I can do it".
Being able to write a sequence of ASCII letters to indicate a string is nice, but then what about other ASCII characters? Other Unicode letters and other Unicode characters? ASCII letters that match keywords in the language? That's where the proposal fails IMO.
Many languages start with a simple rule: A string literal is any sequence of characters enclosed between double quotes. Then someone realises that you can't create a string literal representing a double quote. Three methods are used that are more or less helpful: "" in a string literal doesn't indicate the end of one string literal followed immediately by another one, but means a double quote becomes part of the string literal. Or we use escape sequences, for example \" means a double quote character, \\ means a single backslash character (otherwise we can't include a backslash character in a string literal) and some more. Or we state that a string literal may be enclosed in single quotes instead, which is often a simple solution avoiding escape sequences.
Swift (and others I believe) has multi-line string literals. An example:
let s = """
This is a string literal
containing a line break
"""

Here the string literal can contain anything except a """ sequence, which makes it quite useful to create help text to be displayed on the screen, or source code and so on. It's meaning is clear because the """ at the start and end stand out.
And C has the feature that what looks like two consecutive string literals with nothing but white space in between is merged by the compiler into a single string literal. For example "Hello" ", " "world" and "Hello, world" are compiled to exactly the same string literal. This would be a problem with bare words because now two words are a single string literal with no space between them.
---
### Answer by username_13 on 2023-08-28. Score: -7
In addition to all of the other reasons, consider that when computer languages were first created, computers didn't have the CPU power, memory, and other resources for doing complex code interpretations that a modern, AI-based compiler or interpreter might have.

It might (or might not) be possible to create a reliable interpreter for barewords today, and it might (or might not) have been theoretically possible 80 years ago but it is sure there were other priorities for CPU cycles for most of those 80 years.

Now it is so embedded into our minds and practices, just as it is in our spoken languages, that the cost of keeping it that way is far, far, less than the cost of trying to change it.

Consider that Abraham Lincoln once said four score and seven years ago and computer memory and power has increased by a power of thousands.

Bet you didn't even know that Mr. Lincoln knew about computers, did you?
> **Comments:**
> **username_19** (2023-08-28): What modern compilers or interpreters for programming languages are AI-based?  
> **username_13** (2023-08-28): None that I know of but the reference is about the modern computer capabilities that might (or might not) be of use in interpreting barewords.  Machine learning and AI might be the only way to accomplish barewords interpretation reliably because there would be a seemingly infinite number of scenarios and speech patterns to interpret.  So when I spoke about modern computer compilers and interpreters, in a hypothetical scenario, I used a hypothetical model.  I'm sorry that the reference to AI is all that you got out of my answer.  
> **username_19** (2023-08-28): Well, most of the rest of your answer is unsupported too, but I figured it would be easier to only ask you about one thing. If you only meant this to be speculation then I suggest you edit to remove it. Is there any reason you think supporting barewords would require enormous computational resources, besides speculation? What do speech patterns have to do with it?  
> **username_13** (2023-08-28): Are you suggesting that analyzing every potential bit of text, every statement intended for human consumption that's built into a computer program, across every language, both current and ancient, would NOT take an enormous amount of compute power to review and separate from words having the purpose of communicating intentions from a human to the computer itself?  
> **username_19** (2023-08-28): I am not suggesting that at all, and why would that be necessary to support barewords in a programming language's syntax? Note that some existing languages *do* support them (see other answers for details). I think you have seriously misunderstood the question.  
> **username_13** (2023-08-28): Speech patterns are very critical to doing barewords successfully and reliably.  The goal of most computer programs is to communicate something to a  human being in support of some business decision or objective.  When strings of speech are intermingled with strings of other data and instructions to the computer, itself, how do you differentiate them unless you can isolate the human speech or messages, in every single possible language?  For example, consider my quote from Abraham Lincoln about his view on computer power.  
> **username_13** (2023-08-28): As another pointed out, there are delimiters in those other languages: a space at the beginning and an EOL at the end.  And they don't truly support barewords and at least one mentioned stopped supporting barewords - because it can't truly be done reliably and completely - at least  not without huge computing power and maching learning/AI.  A  human can never write enough code to parse out every possible human language phrase from computer instruction.  I'm not going to continue to argue; I've offered my reply and comments and they can be voted on. Peace out.  
> **username_21** (2023-08-28): Unix shell has unquoted string values and dates back more than fifty years; I don't see how this CPU-power argument holds water and it would help to [edit] the answer to provide some more backing to the claims it makes.  
> **username_19** (2023-08-28): You differentiate them either in the language's grammar, by allowing them in certain places where the parser knows that bare identifiers are string literals; or otherwise you differentiate them after parsing by finding whether the identifier corresponds with a named declaration and, if it doesn't, treating it as a string literal. Or both. Those are completely reliable ways, unlike anything based on a probabilistic AI language model with no formally specified behaviour. It sounds like you have taken the question to mean the compiler must have human intelligence, but that is not what it's about.  
> **username_13** (2023-08-28): @MichaelHomer, Unix has unquoted strings but it doesn't have undelimited strings. Try this command in Linux or Unix:  mkdir "test directory" and tell me how it works out for you - oh, you can't comprehend my instructions without delimiters or marks so I added the quotes.  Don't add the quotes when you run the command.  
> **username_13** (2023-08-28): I didn't say the compiler needed human intelligence.  AI is not human intelligence.  That seems to be a mistake on your part.  AI is built on evaluating typically huge datasets and learning patterns from that data.  That doesn't make AI human or even human-like.  It simply means that it can learn in advance from previous knowledge versus doing a few hundred trillion regex calculations in answer to a single command such as print first name.  ML comes in to basically add to that knowledge from real time or new input.  
> **username_13** (2023-08-28): The OP's question can never be answered absolutely and every answer is, in the end, speculation.  If anyone thinks that you can consistently and reliably, in all cases, mix code with strings meant for human consumption, without huge computing power, tell how that would happen and where it's happening today.  And don't forget that even the code we write is only intended for human readers, as well.  Computers don't understand C or JavaScript.  Computers don't understand assembly.  They understand binary.  
> **username_13** (2023-08-28): @kaya3, differentiating by patterns in the programming language is most certainly not a reliable way to do it.  First off, that requires telling every speaker of 7139 spoken languages that they can't say certain things in certain ways because my compiler will get confused.  And what if I am writing a code review program?  My program requires the ability to offer the programmer suggestions how to properly accomplish something they violated.  Now my data and my output look exactly like my syntax.  The compiler must, in every case, properly tell the difference.  
> **username_0** (2023-08-29): Forgive me, but I don't get the Lincoln reference. How do computers tie in with the Gettysburg Address?  
> **username_22** (2023-08-29): *"Consider that Abraham Lincoln once said four score and seven years ago and computer memory and power has increased by a power of thousands."* - a "Chewbacca defence" if I ever saw one!  
> **username_23** (2023-08-29): @kaya3 I'm not sure if I understood the OP correctly, but if I did, the idea is a compiler that can automatically distinguish bare words from variable names: If you write `myVariable = Hello`, the compiler automatically "knows" if the string constant `"Hello"` or a variable named `Hello` is meant. *Maybe* an AI-based compiler would be able to do this (I doubt about that).  
> **username_13** (2023-08-29): @SafwanSamsudeen, computers don't tie into the Gettysburg Address.  The point was two separate ideas but without quotes they don't appear as separate ideas.  Also see my example of mkdir test directory.  This whole idea got blown up because someone argued whether it took a lot of computer resources to do barewords, arguing minutiae rather than the point that early computers certainly didn't have the power to sort out such things and the pattern of using quotes was established early and no one wants to put in the effort to change it now.  
> **username_24** (2023-08-30): @Dale what makes you think that early computers couldn't have handled that computation? You've repeatedly _asserted_ it, but you haven't _justified_ it at any point.  
> **username_0** (2023-08-30): @Dale I appreciate your effort to answer. Next time, I recommend you back it up with more references/facts and a clearer argument (the Lincoln ref was definitely confusing). All the same, thanks! I see you're a new contributor, and I hope this experience doesn't push you off contributing. Best of luck!  
> **username_25** (2023-09-10): This answer is missing the foundational contributions of Gödel and Quine. Quotation is akin to a modality and requires some sort of marker in formal logic.  
---
