Cyclic imports

[chtenb]

A show implementation for vector could look like this:

pub fun show( xs : vector<a>, ?show : a -> e string ) : e string
  "vec[" ++ xs.map(show).join(",") ++ "]"

However, it is currently not possible to add this to the std/core/vector module, because the join function is imported from std/core/string, which in turn imports std/core/vector, constituting a cyclic dependency.
What is the current vision of the language developers on how to deal with this issue?
Is there an intention to support cyclic imports in the future?

[TimWhiting]

I don't think there is any intent to support cyclic imports (similar to Haskell, etc). @daanx am I correct on this?

Mutually recursive definitions should be defined in the same module.

It is a bit tricky for the core modules, (which is why they used to be in just one big module).

However, in the problem above, there really isn't a mutually recursive definition, it is just that some definitions from one module want to depend on definitions from the other module in a way that dependencies are a non-cyclic tree. For example, join could be placed into the core "types" module, since it mostly relegates to the extern definitions, and then imported from both std/core/string and std/core/vector (re-exported). But obviously that is not very satisfying from the organizational perspective and naming of the types module, but we could have a different internal module to house 'common' definitions like these.

Another solution could be to also make the join parameter implicit since the two modules should always be in scope together.

pub fun show( xs : vector<a>, ?show : a -> e string, ?join: (vector<string>,string) -> string) : e string
  "vec[" ++ xs.map(show).join(",") ++ "]"

I think this is a nice solution to the problem.

In other words:

1. For mutually recursive type definitions, the natural location for their functions which will likely often be mutually recursive are in their same module.
2. For functions that are not mutually recursive, but one function in one module depends on another from the other module, and vice versa for at least one other function. Either: move the core types and functions to a place both modules can reach, or: use implicits to delay resolution of one of the functions, and make sure that either both modules are publicly exported from a common module, or document that that function requires the other module to be imported as well - which will likely already be the case most of the time?

I think moving the types and core functions into a more 'base' module is probably the best solution for the most part. Remember we are assuming there are not mutually recursive definitions that would require this anyways. I think the solution using implicits is probably mostly for special cases (such as due to some design or organizational aspects of the std libraries).