2

This is basically a continuation of "Why don't languages auto import everything?" but with a slightly altered premisse:

Say we have a language like C++ / python that uses namespaces to distinguish functions and classes from other modules, would it not in theory be possible to leave out all the includes / imports and have the compiler automatically resolve the tokens back to the corresponding library?

The way this would work is that the build system puts the dependencies into the compilers context, and the compiler will search through a complete index of tokens directly instead of going through the imported modules.

The imports can sometimes be resolved by modern IDE's, but this is never at the language level and even for modern languages you need to do it. Why though?

Consider this simple case:

#include <iostream> int main() { std::cout << "Hello World" << std::endl; }

In 99% of the cases the user wants to import std::cout from iostream. While C++ can't necessarily guarantee that there isn't a competing std::cout out there, a language designed with this in mind could potentially (hypothesis). So why isn't it done?

A huge benefit would be that refactorings would become so much easier, since you don't have to flip through all your dependencies to check which ones to import and which not (even of course LSP's will make that easier). And at the same time you're never importing too much, only the tokens that you really need...

The question is: Is it necessary or just tradition?

Improve this question
11
  • 1
    Your question is unclear. Do you only want to spare the imports/includes, or any kind of dependency definition / library referencing? Commented Jan 14 at 15:25
  • 2
    It's easy enough with something obvious like cout, I'm not as sure that it's easy when you consider the entire family of things that may be pulled in by a simple-looking #include <iostream>, especially considering that (currently) the include is purely textual and performed by the pre-processor (so the existence of it is gone by the time the compiler takes a crack at it). Commented Jan 14 at 15:36
  • 2
    "While C++ can't necessarily guarantee that there isn't a competing std::cout out there, a language designed with this in mind could potentially (hypothesis)." How do you prevent two independent developers (or teams) from creating the same names? I don't see a way for a programming language (alone) to prevent that. Commented Jan 14 at 16:36
  • 2
    This question is similar to: Why don't languages auto import everything?. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem. Commented Jan 14 at 20:34
  • 2
    Even in your own example, you assert that the inference logic isn't ironclad, there is a 1% edge case. Time and time again, programming teaching you that logic requires you to be pedantically unambiguous about everything you mention, specifically because the logic/compiler refuses to make educated guesses. Your question is just another example of the same thing. Commented Jan 21 at 5:32

5 Answers 5

Reset to default
8

It is not necessary. Some languages already have this functionality, e.g. C# and I think Java. In C# the using X statement doesn't import anything, it only makes the code shortened by telling the compiler: "things in this file should be tested with X... namespace". All "things" in a given project are available through their full (including namespace) name, regardless of using statements. Of course even in C# you are restricted to a single project, you have to explicitly include other projects for them to be importable (although the std is included by default).

We have similar situation with Rust, where once you declare a module in main.rs or lib.rs it becomes visible everywhere inside a project (a.k.a. crate) through its full path. This also applies to external dependencies. However Rust gives more granual control over what is visible or not, so the above is true only for pub modules/things. Unlike C# where top level things (classes, structs, interfaces, etc) are always visible inside project.

For other languages it might not be possible and it is a case by case study. For example Python is a very dynamic language. Python files can execute arbitrary code at the top level, including i/o. Well, tbh C# nowadays can do this as well through module initializers, but at least at project level, not file level. And also it is rarely used feature. Regardless you have to be careful about importing external libs (which is not really a surprise).

Anyway running i/o (or cpu intensive) code at top level of Python file is an antipattern, but unfortunately is not uncommon. And so you don't want to import anything that you don't use. Note that the dynamic nature of Python does not allow for proper static analysis of its own files (meaning: you cannot import a Python file without executing it), since Python can modify its own classes/functions at runtime. Also, Python can run in shell mode, which would be an additional challenge (should starting shell import everything? from entire disk? what if I change dir?).

C of course is a very old language, and since many fundamental libs (and operating systems) are written in C, it is unlikely to ever change. But this is purely historical + backwards compatibility argument. It could work differently, it just doesn't for reasons (likely loading and analyzing all files at the same time was just too heavy 50 years ago). Also, include statements in C/C++ have a weird side effect, that these can be evaluated multiple times during compilation and produce errors (because of duplicate definitions). Something that is avoided nowadays through include guards but worth mentioning I guess. It is even possible for include to produce a different output each time, but this is even worse. The compilation process of C/C++ has its own life.

Improve this answer
14
  • I would say that the C# using has almost exactly the same behavior as the C++ using namespace. The main difference that I can think of is that C# using will add extension methods for potential name resolution. Commented Jan 14 at 15:33
  • 2
    @Craig which is contrast to include statements in C++. Commented Jan 14 at 15:35
  • 1
    @Craig project/assembly, whatever. It is not like include: again, you cannot refer to any other file in C++ without include. And most includes are internal. While I don't need any <Reference> to work on a C# project. These are not alike at all. Commented Jan 14 at 15:43
  • 1
    @Craig the only program you can write in C without includes is return 0; in main(). Sorry, you won't even print anything, and forget about anything more complex. And it is not about importing system libs, as I already said: I can refer to any class/thing in my entire project without includes. How is that related to other assemblies? It is not at all. Commented Jan 14 at 15:47
  • 1
    @Craig no, you don't have to use using to use a C# class from another file, regardless of namespace. As long as it is in the same project. You just refer to it through its full name. using is just there to make the (following) text shorter, that's all. And in C++ you cannot use a class from another file without include directive. Even in the same project. Unless there are some shenanigans that I'm not aware of. Commented Jan 14 at 15:53
4

In some cases, this can introduce disturbingly long dependency chains, and have the potential for a lot of false positives. Consider, for example, your own example:

#include <iostream> int main() { std::cout << "Hello World" << std::endl; }

The compiler can tell what std::cout is, and that it must be the one provided in <iostream> (since redefining it would be UB, and thus Never Happens™). But then it would look at <iostream>, and realise that <iostream> includes <ios>, which has this function:

explicit std::ios_base::failure::failure( const std::string& message );

It would then look std::string up, and find that it's defined in header <string>... and in header <stacktrace>. And <system_error>. And declared (and probably defined) in <stdexcept>, and the entire streaming I/O system (thanks to <ios>), and probably in other places, too. And if it doesn't have an aneurysm trying to sort that all out, it would realise that actually, std::string is really defined in a secret internal file (such as <xstring> on MSVC), and cheerfully include that instead.

And by doing so, it would miss that all of the tools that std::basic_string is designed to work with are in <string>, creating a false sense of security and potential errors that won't be discovered unless you use something that's explicitly part of <string> and no other headers, such as std::char_traits. Not only that, it would also notice that std::basic_string depends on std::allocator, work out that it's in <memory>, and that <memory> depends on either <cstddef> or an internal file that <cstddef> typically includes...

So, just by automagically looking up <iostream> for you, we introduce the possibility of at least 8 false positives (for std::string's definition's location), one of which is recursive (<iostream> itself typically provides std::string). And that's even before we get to the types that any of their dependencies include!

Overall, this sort of problem can be avoided, but it would take a lot of work for very little benefit. (And in fact, the std::string ambiguity suggests that it could actually be overall detrimental; we "know" that we need to include <string> for string, which is what gives us all the string helpers. If the compiler guesses incorrectly and accidentally includes <xstring>, and we then use std::to_string(), it'll be forced to do another lookup and include <string> as well; this loses time at best, and risks silently breaking things at worst.)

The problem leads to one conclusion: If a language is expected to do automatic standard-library name lookup, then both it and its environment need to be designed from the ground up to do so, because it forces specific internal library paradigms. Trying to backport it into a language that lacks those paradigms will likely be more trouble than it's worth.

Improve this answer
1

Say we have a language like C++ / python that uses namespaces to distinguish functions and classes from other modules, would it not in theory be possible to leave out all the includes / imports and have the compiler automatically resolve the tokens back to the corresponding library?

There are slightly different issues for different languages.

One language agnostic point is that the semantic noise of having a bunch of imports at the top of a file can actually be a useful indicator of how many dependencies a file is accruing.

Without this, we need some way for the compile/build system/runtime to emit a dependency report which will be equivalent to the includes/imports we just removed - and we need to manually request and check this to get some sense of how messy our dependency graph is getting.

C++

  • this is based on C which absolutely does not use namespaces and can't use this mechanism, so we need to keep include statements for this (or make a breaking change to lose C compatibility)
  • include statements also have some idiomatic uses which are not module-like or idempotent - typically using different macros to expand the same declarative text - so we need to keep include statements for this (or make a breaking change to require a standalone code-generation step, or add a richer macro system, or compile-time reflection, or...)
  • the evaluation of C++ is path-dependent, particularly in libraries that use a lot of macros (eg. Boost), so the design of library headers would need to change significantly. Macros themselves are not namespaced (since they're inherited from C, and anyway managed during an earlier phase of compilation)

Conclusion a version of C++ that used implied module imports exclusively, replacing #include statements would be a completely different and incompatible language with similar syntax.

Doing it implicitly for certain well-defined modules could work, but now you have 3 different ways of importing dependencies rather than 2. You're strictly increasing build system and language complexity, largely to benefit Hello, World programs.

Python

  • modules can execute code at the top level when they're imported (even the apparently-declarative module setup is code), but that presumably shouldn't happen just when they're scanned ...
  • ... although the list of names exported by the module is produced by that code, so it needs to be evaluated somehow ...
  • we need to either pull in dependencies on first use, or we need to scan a program once to generate the dependency graph and then synthesize the imports it would previously have had
    • the first, lazy-loading style, will change the order in which modules are initialized, and a program might run part-way through before a dependency fails. That sounds bad.
    • the second, greedy style, requires two passes and may cause programs to fail that previously succceeded: perhaps a dependency is missing but only used on one conditional branch, and you're always taking the other.

For your scheme to work well, I think we ideally need module definitions to be purely declarative and idempotent, and to have a new language with no historical baggage.

Once you have this language, you'll note that this point

A huge benefit would be that refactorings would become so much easier, since you don't have to flip through all your dependencies to check which ones to import ...

is moot, since any language compiler or runtime that can correctly infer the correct imports, can trivially generate the correct import block at the top of the file.

If it doesn't do that, you still (per my first point) want a visible dependency report somewhere you have to actually read it. Just putting it in the source file is probably simplest...

Improve this answer
1

Some languages work like this, for example BASIC. But this approach does not scale to more complex applications and ecosystems since such a language will not support third-party libraries well.

For names to automatically imported they must be unique. You can't have namespaces. The standard library of the language can be designed such that all names are unique, and you can write your own code to ensure all names are unique and does not collide with names in the standard library. But there is no way to ensure two independently developed libraries doesn't use the same name. So you can easily end up with two libraries which cannot be used together because they define the same name.

JavaScript existed for a long time without any kind of module system. You could have multiple script files, but if two files defined the same name, the second would just overwrite the first definition. This worked for a while since scripts were small. Third-party libraries like JQuery were careful to define as few global names as possible to avoid collisions (I believe JQuery only defined one). But this doesn't scale when you combine multiple third-party libraries which in turn require their own dependencies, which is why a module system was added to the language.

Improve this answer
6
  • If namespaces are designed to be unique, the that would work I guess. Commented Jan 16 at 14:48
  • @glades you can't have namespaces, since this would introduce ambiguities when a name is defined in multiple namespaces. Commented Jan 18 at 11:59
  • Yes and no, I meant that you'd always have to fully qualify the functions you use to make it deterministic. Commented Jan 18 at 12:45
  • 1
    @glades: You would still have the problem if two independent modules used the same namespace. You would need some kind of global registry to avoid that. Commented Jan 18 at 14:29
  • 2
    @glades: Good point. For example the Java convention is to use namespaces based on the domain name system which is a global registry. Arguably Java and C# already works like you describe since you don't need to import anything if you always use the fully qualified names. Commented Jan 19 at 16:28
-1

In some languages you can have two functions both named f() but with different argument types. And if the compiler knows only one it calls that; if it knows both it calls the one matching better.

This means making both f’s visible to the compiler can change the semantics, and you really don’t want that.

On the other hand, in Swift you define a “compiler target” and all source files that are part of that target. And all definitions that in that target are taken into account simultaneously.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.