<p>Why is it that languages like C/C++/Go and others have</p>
<pre><code>import-keyword &quot;libraryName.fileExtension&quot;
</code></pre>
<p>When something like</p>
<pre><code>import-keyword libraryName
</code></pre>
<p>Has been shown to work fine?</p>

<syntax>
Why do some languages have quotes around imports?
CC BY-SA 4.0
2024-05-14T17:06:14.980Z
Is this question about importing _libraries_ (as per the example's content), or _files_ (as per its syntax), or other things?  (For example, Java and similar languages import _symbols_ into the current scope, and so neither need nor use any delimiters.  But that clearly can't work for filenames.)
gidds
CC BY-SA 4.0
2023-05-17T00:35:29.527Z
I think this is confusing the use of string syntax in C/C++ for includes with the actual use of strings, as in IIRC JavaScript. It's worth mentioning the existence of angle bracket includes in C++, with somewhat different semantics, and I suspect this is ultimately a historical question.
Unrelated String
<h1>Import paths not in strings may be invalid/illegal syntax in the language.</h1>
<p>Go (one of your mentioned languages) allows URLs in its import paths. If we had a &quot;bare&quot; import like <code>import example.com/example-mod/packagename</code>, this would yield a whole slew of syntax errors, because (usually) URLs as-is are not syntactically legal Go.</p>

CC BY-SA 4.0
2023-06-26T18:51:10.283Z
2023-06-30T19:05:53.830Z
2023-06-30T19:05:53.830Z
bigyihsuan
<h1>Importing without built-in syntax</h1>
<p>In some languages like Ruby, Lua and Zig, there is no special syntax for imports. Instead, importing is done using a regular function. Since it's a regular function, it has to take the name as a string, not as an identifier.</p>

CC BY-SA 4.0
2023-07-19T08:28:37.207Z
2023-07-19T08:28:37.207Z
xigoi
<h1>Extensibility over time</h1>
<p>One reason for doing this is to allow a more extensible range of imports over time or across platforms. New behaviour can be added to the interpretation of the string later on without changing the fundamental syntax, so existing parsers continue to work.</p>
<p>For example, a later addition of language-level version numbering to imports would require a syntactic change in Python (which uses the <code>import libraryname</code> format) but not in JavaScript modules, which use host-defined strings. Similarly, relative (or absolute) imports could be added simply by reusing the string.</p>
<hr />
<h1>Imports that <em>aren't code</em></h1>
<p>Another possibility is that you may be able to import files that <em>aren't code libraries at all</em>: perhaps <code>import &quot;logo.jpg&quot; as logo : Image</code> makes sense in this context, or <code>import &quot;documentation.txt&quot;</code> or <code>import &quot;https://example.com/data.json&quot;</code> . Resource imports like this could be quite powerful, but they do require being able to identify the location of the resource precisely.</p>
<p>You might even be able to import things that aren't files at all: perhaps a database connection or web service, in the manner of F# type providers. For reference examples of this sort of thing I'll point to (cough) <a href="https://mwh.nz/pubs/dyla2013" rel="noreferrer">this distant paper</a> of mine and chapter 5 of <a href="https://michael.homer.nz/Thesis" rel="noreferrer">my thesis</a>, which discussed a few different options. There have been further developments in this vein over the last ten years.</p>
<p>It's not obviously <em>good</em> to overload the import system in this way, but it's not inherently bad either. Explicit imports can invoke static checking and resolution in a way that dynamic loading of data at run time can't, can be interpreted by packaging systems, and can offer uniform access to local, generated, and remote resources.</p>
<hr />
<h1>Identifier limitations</h1>
<p>Strings may also encode values that aren't permitted in identifiers within the language, from odd characters in local file paths to URLs or beyond. The interpretation of the string is left up to the implementation.</p>
<p>It's not unreasonable for a language to project its identifier rules onto module names and define a fixed correspondence between them, but it's not necessary to do so always. In some cases, like for JavaScript, importing from arbitrary URLs is an expected need for real users, so a format that allows for that makes sense.</p>
<hr />
<p>None of these are <em>the</em> reason for C (though in part perhaps for Go), which is how it is for historical reasons of its early days. New languages, and new import systems like JavaScript's, are more likely to follow one of the other reasons.</p>

CC BY-SA 4.0
2023-05-17T00:52:31.897Z
2023-05-17T00:52:31.897Z
Michael Homer
<h1>The C Preprocessor</h1>
<p>C's preprocessor simply looks for a file with that name and copy-pastes its contents. Strings allow your filenames to contain whatever characters and have whatever extension without confusing the preprocessor. Furthermore, the delimiter used (<code>&quot;&quot;</code> vs <code>&lt;&gt;</code>) tells it where to look.</p>
<p>Symbolic imports, like those used by Java, weren't as much of a proven thing when C was designed (over 50 years ago!). Besides, they rely on enforcing filenames and in some cases folder structure.</p>

CC BY-SA 4.0
2023-05-17T00:35:52.937Z
2023-05-17T00:35:52.937Z
Bbrk24
<p>Usually you can have whitespaces in:</p>
<ul>
<li>String literals</li>
<li>File names</li>
<li>URLs (well, if you escape them)</li>
</ul>
<p>While you cannot have whitespaces in:</p>
<ul>
<li>Identifiers</li>
</ul>
<p>So if you want to import from whatever file, using string literals is a good idea compared to an identifier.
Also, identifiers usually have something to do with variable/type/function names, so if you have identifier-based module names, then it's a good idea to use identifiers instead.</p>

CC BY-SA 4.0
2023-05-17T00:36:22.217Z
2023-07-01T16:16:16.307Z
2023-07-01T16:16:16.307Z
ice1000
# Why do some languages have quotes around imports?
Posted by: username_0 on 2023-05-17
Why is it that languages like C/C++/Go and others have
import-keyword "libraryName.fileExtension"

When something like
import-keyword libraryName

Has been shown to work fine?
**Tags:** syntax
> **Comments:**
> **username_2**: I think this is confusing the use of string syntax in C/C++ for includes with the actual use of strings, as in IIRC JavaScript. It's worth mentioning the existence of angle bracket includes in C++, with somewhat different semantics, and I suspect this is ultimately a historical question.  
> **username_1**: Is this question about importing _libraries_ (as per the example's content), or _files_ (as per its syntax), or other things?  (For example, Java and similar languages import _symbols_ into the current scope, and so neither need nor use any delimiters.  But that clearly can't work for filenames.)  
---
## 5 answers
### Answer by username_7 on 2023-05-17. Score: 19
Usually you can have whitespaces in:

* String literals
* File names
* URLs (well, if you escape them)

While you cannot have whitespaces in:

* Identifiers

So if you want to import from whatever file, using string literals is a good idea compared to an identifier.
Also, identifiers usually have something to do with variable/type/function names, so if you have identifier-based module names, then it's a good idea to use identifiers instead.
---
### Answer by username_5 on 2023-05-17. Score: 13
# Extensibility over time

One reason for doing this is to allow a more extensible range of imports over time or across platforms. New behaviour can be added to the interpretation of the string later on without changing the fundamental syntax, so existing parsers continue to work.

For example, a later addition of language-level version numbering to imports would require a syntactic change in Python (which uses the `import libraryname` format) but not in JavaScript modules, which use host-defined strings. Similarly, relative (or absolute) imports could be added simply by reusing the string.

---

# Imports that *aren't code*

Another possibility is that you may be able to import files that *aren't code libraries at all*: perhaps `import "logo.jpg" as logo : Image` makes sense in this context, or `import "documentation.txt"` or `import "https://example.com/data.json"` . Resource imports like this could be quite powerful, but they do require being able to identify the location of the resource precisely.

You might even be able to import things that aren't files at all: perhaps a database connection or web service, in the manner of F# type providers. For reference examples of this sort of thing I'll point to (cough) [this distant paper](https://mwh.nz/pubs/dyla2013) of mine and chapter 5 of [my thesis](https://michael.homer.nz/Thesis), which discussed a few different options. There have been further developments in this vein over the last ten years.

It's not obviously *good* to overload the import system in this way, but it's not inherently bad either. Explicit imports can invoke static checking and resolution in a way that dynamic loading of data at run time can't, can be interpreted by packaging systems, and can offer uniform access to local, generated, and remote resources.

---

# Identifier limitations

Strings may also encode values that aren't permitted in identifiers within the language, from odd characters in local file paths to URLs or beyond. The interpretation of the string is left up to the implementation.

It's not unreasonable for a language to project its identifier rules onto module names and define a fixed correspondence between them, but it's not necessary to do so always. In some cases, like for JavaScript, importing from arbitrary URLs is an expected need for real users, so a format that allows for that makes sense.

---

None of these are *the* reason for C (though in part perhaps for Go), which is how it is for historical reasons of its early days. New languages, and new import systems like JavaScript's, are more likely to follow one of the other reasons.
---
### Answer by username_6 on 2023-05-17. Score: 10
# The C Preprocessor

C's preprocessor simply looks for a file with that name and copy-pastes its contents. Strings allow your filenames to contain whatever characters and have whatever extension without confusing the preprocessor. Furthermore, the delimiter used (`""` vs `<>`) tells it where to look.

Symbolic imports, like those used by Java, weren't as much of a proven thing when C was designed (over 50 years ago!). Besides, they rely on enforcing filenames and in some cases folder structure.
---
### Answer by username_4 on 2023-07-19. Score: 8
# Importing without built-in syntax

In some languages like Ruby, Lua and Zig, there is no special syntax for imports. Instead, importing is done using a regular function. Since it's a regular function, it has to take the name as a string, not as an identifier.
---
### Answer by username_3 on 2023-06-26. Score: 5
# Import paths not in strings may be invalid/illegal syntax in the language.

Go (one of your mentioned languages) allows URLs in its import paths. If we had a "bare" import like `import example.com/example-mod/packagename`, this would yield a whole slew of syntax errors, because (usually) URLs as-is are not syntactically legal Go.
---
