design for bosatsu libraries

[johnynek]

• Libraries are the units of code sharing.
• Packages are sets of 0 or more values and 0 or more type definitions.
• Libraries are sets of 0 or more packages.
• Libraries are versioned. We can compute the version of a library given the previous version and library.
• Libraries can depend on 0 or more other Libraries. That dependency graph forms a DAG.
• Libraries can have private (unexported) packages. Like packages, exporting values and types is opt-in, not opt out. Libraries export at the level of packages, not values. All transitively visible types from exported packages must be inside exported packages.
• Libraries can have public and private Library dependencies. A private dependency means that none of the values or types in that dependency Library appear on publicly visible values or types of the current library.
• The transitive set of dependencies that are reachable with more than one path ("diamond dependencies") must have a valid version that satisfies all the dependents: open question: should we declare in a Library the values and types that it depends on from public dependencies? In this way we can with library definitions we can compute if a given version will satisfy a dependency and we can unambiguously solve for a common version. Alternatively, we could use version ranges and semver, which simplifies the satsifiability checking but at the expense of more brittle dependencies (sometimes a Library changes in an incompatible way, but a dependency doesn't use that aspect of the library).
• A library declares a solution for all transitive public dependencies, not just direct dependencies.
• When considering a library, the set of reachable private libraries do not need to share a single version. This significantly complicates linking since we need to link each package import to a specific version of a package.

[johnynek]

If every library solves for a valid transitive set of public libraries then when adding dependencies, all diamonds are visible directly. So, if there is no collision in that list, you don't have a new diamond. If there is a collision, there is a set of candidate dependencies, and we can check each of those for all the N-1 others.

There should be a tool where we take the declared inputs, and then we generate the checked library output which would include the solutions to the current library, the previous version of the current library, and the hash of all the referenced libraries.

[johnynek]

We could make a projection of a dependency by taking the union of all imports. So, a library could have a projected inferface that it depends on. This goes in the direction of doing a full solution of the dependency problem, and in this view, the version numbers don't really matter except that they are ordered so we can identify which ones come later.

[johnynek]

Since when compiling, all diamond dependencies are solvable, that means the interfaces are compatible. So compiling each package isn't a problem. But once we have compiled and we are linking and emitting code, we need to know which version of the code we need to link to each package. We could merge them into a single namespace by appending an identifier for the version onto the names emitted when there is more than one, or we could use directories / package names.

Since ultimately, I'd like a C compilation target, it seems like appending versions to the names is the better approach.