|
|
|
|
|
|
by marcus_holmes
2420 days ago
|
|
|
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? |
|
|
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.