prql_compiler::semantic module

[aljazerzen]

@not-my-profile what did you have in mind when you created prql_compiler::semantic::resolver module? I don't get the separation between files in prql_compiler::semantic and prql_compiler::semantic::resolver and would think that prql_compiler::semantic::resolver could be flattened so we have just the prql_compiler::semantic.

I wanted to ask about this before moving files so we don't get too much conflicts, since you said you are working on semantic too.

[aljazerzen]

I don't know where to say this since you are not on our Discord, so I'll say it here:

The split of the AST crate makes much more sense after poking around the codebase. Before, we were leaking internal stuff of the resolver into the AST, so this change set up a "border" between the two abstractions quite nicely.

It also gave me ideas of how to create more "complexity bottlenecks", so the resolver could be simplified a bit. This is a good example of how collaboration births new ideas which would not be possible when working alone.

I hope if don't irritate you too much with code reviews - I'm a bit protective of the code that I've written :D I'll try to hold that back and keep in mind that refactors of my code are not saying "your code is bad".

[not-my-profile]

I did not create the resolver module. The module already existed ... I just moved stuff that's only used by that module into that module (5198e86, 6ee3555 and bfdb624) ... which is generally good practice in any codebase ... keeping stuff close to where it's used and reducing the visibility of stuff as much as possible ... it makes it easier to understand what belongs to what and enables refactors within a module that don't require any changes outside of the module.

For instance transforms and the type_resolver are conceptually part of the resolver ... they're only used by it and by nothing else. So I think it is completely obvious that they should reside within the resolver module. We may even want to break the compiler great apart into further crates in the future ... having a proper module structure helps with that.

[aljazerzen]

it makes it easier to understand what belongs to what and enables refactors within a module that don't require any changes outside of the module

That makes sense. I'm just confused where's what, stumbling from place to place where it used to be.

I'll probably move a few things around, so I don't have to search trough many files named mod.rs. But I have to figure out how organizer the resolver now.