Simple module/import implementation#293
Conversation
|
Notes for reviewers: (edited) I added a few comments about temporary TODOs that will be resolved later in this patchset. Unfortunately I rebased the PR after I did so -- I think that github has lost the connection with which commit they came from. It would be worth keeping this in mind when reviewing commit-by-commit. This PR is an alternative to #263. Note that the bulk of the changes are pretty mechanical. |
|
The test suite failure is mostly (4 tests) due to serialisation changes which I didn't notice because of #294. There is one that needs more investigation though: |
Looks like that's been broken by changes to |
georgefst
left a comment
georgefst
left a comment
There was a problem hiding this comment.
Looks good! Once tests pass, of course.
brprice
force-pushed
the
brprice/fix-defaultPrimsProg
branch
from
59d07e6 to
32e1cae
Compare
brprice
force-pushed
the
brprice/modules
branch
from
13896ec to
1663324
Compare
This is in preparation for having a Prog include imported modules. BREAKING CHANGE: this change requires a database migration, as it changes the representation of `Prog`. However, since this is just serialised to json and stored as a blob in the DB, it requires no schema changes. Since we have no programs we need to preserve, we decided not to bother with a migration. This means that DBs created before this commit will not load with a primer containing this commit.
We will shortly want to import Primer.Core(defID), and want to avoid CI failures due to -Werror -Wname-shadowing.
We enable Primer programs to import modules. This is achieved by adding a `progImports :: [Module]` field to `Prog`. The imported modules are each immutable (via the api). This immutability is ensured by having all the actions only operate on the one "current" module (that comprises the old `progDefs` and `progTypes`). (For now, the set itself is also immutable via the api.) For now we don't have any namespacing, we just lookup references in all modules and assume unique names. We leave adding hierarchical names for future work. We also leave having multiple editable modules for future work. BREAKING CHANGE: this change requires a database migration, as it changes the representation of `Prog`. However, since this is just serialised to json and stored as a blob in the DB, it requires no schema changes. Since we have no programs we need to preserve, we decided not to bother with a migration. This means that DBs created before this commit will not load with a primer containing this commit.
This is basically an action, except we don't expose it in the API. We will delay doing so until we have a nice way for a frontend to refer to a module. I.e. we would like to say "import the User1.ProjectFoo.ModuleBar" module, rather than having to explicitly give the code contained within the module. This utility does not check that imported modules have disjointly-named contents. We intend to shortly require a hierarchical naming scheme which will address this concern. At that point we will also address the issue of disjoint IDs of contents, and our freshness guarantees. The reason we delay worrying about disjointness/uniqueness is that both it and being able to expose this nicely in the API require the notion of a module having some short name, rather than having to explicitly pass around all the code contained in the module.
brprice
force-pushed
the
brprice/modules
branch
from
1663324 to
e67f0b9
Compare
|
@Mergifyio refresh |
✅ Pull request refreshed |
dhess
added
Ready to merge
|
@Mergifyio refresh |
✅ Pull request refreshed |
|
@Mergifyio refresh |
✅ Pull request refreshed |
|
Note: I couldn’t figure out why this wasn’t building in Mergify. It’s because it had unresolved comments, but that wasn’t clear from the GitHub status for Mergify. That seems like a bug to me. Anyway, for future reference, if a PR is stuck, maintainers can go to https://dashboard.mergify.com/github/hackworthltd/repo/primer/config-editor?repositoryName=primer and use the “Check my configuration on pull request #” functionality for a real-time check. |
|
|
||
| -- | Get all type definitions from all modules (including imports) | ||
| allTypes :: Prog -> [TypeDef] | ||
| allTypes = moduleTypes . progModule |
There was a problem hiding this comment.
I missed this at the time of review - why does allTypes look at imports when allDefs does not? This seems to contradict its comment.
3 participants
We enable Primer programs to import modules. This is achieved by adding a
progImports :: [Module]field toProg. (We also move the currentprogDefsandprogTypesinto aModule.) The imported modules are each immutable, and one can only add more modules to the imported set. This immutability is ensured by having all the actions only operate on the one "current" module (that comprises the oldprogDefsandprogTypes).For now we don't have any namespacing, we just lookup references in all modules and assume unique names. We leave adding hierarchical names for future work. We also leave having multiple editable modules for future work. This work should also address the fact that we look up global terms by ID which "should be unique" (we should probably scope this so IDs only need to be unique in one given module).