[skohan]

File systems aren't without their advantages. One huge advantage is that text files are extremely un-opinionated about how they're used. If my project exists as a tree of directories with text files inside, there are a ton of tools which can operate on them without any knowledge of my program or even programming language. I can open them in vim or my favorite IDE, dump them to the console with cat, manage versions with git and so on. Basically text files are one of the fundamental building blocks of *nix so having my project represented as files means I can leverage decades of tooling.

It's not to say that it couldn't work to have a program represented as some kind of a database or API, but that would imply much tighter binding between tools and their storage representation.

[marcus_holmes]

interesting. But if you assume functions don't intrinsically live in files, they just do that because we have a file-based storage system, and that functions actually live in, say, scopes, then what does that do to your tools?

Can we have a Vim that understands (e.g) scopes natively rather than files?

[skohan]

> Can we have a Vim that understands (e.g) scopes natively rather than files?

Sure we can have a vim that does that. But as I say, it would require tighter binding between the tooling and the code representation.

Right now vim only has to understand code as lines of text separated by spaces, newlines, and tabs. The semantics of that code are the business of the build system and the compiler. The same goes for git. As a result, tools like git and vim can operate on code of any language which is represented as text. That could be an popular language like Java or Go, or some weird experimental language you dream up yourself.

If, as you suggest, the storage representation of the language were tied to the semantics of the language, rather than some external format, then all the tools need to have a deeper understanding of the language itself in order to operate on that storage.

You could try to make it general: i.e. design an organizational structure based on "scopes" which should apply to all languages, but then what if a language comes along which doesn't fit neatly into the "scopes" paradigm? Now you put yourself into a position where you might be making language design decisions which are based on what's possible with the tooling, rather than what's the best possible choice for the language?

Decoupling the storage method from the semantics of the language obviates these problems.

[marcus_holmes]

thanks for the answer, that's interesting.

We do have this to a certain extent now, though - file scope is a thing in some languages.

I'll give up my plan to write a neovim plugin for scope management, though ;)

[TeMPOraL]

It would have to not just understand scopes, but their sequential relationship. In most languages, scopes don't just exist, they are loaded, in a particular order. There are "top-level" effects that happen from loading a piece of code into compiler/runtime until the end. Maybe this is different in purely functional languages (though I suspect not at compilation level).