Open Goju-Ryu opened 1 day ago
I stumbled over this topic in numbat once earlier and I think it is actually possible at the moment to have cyclical dependencies of modules on each other as long as the actual functions/function calls in them don't cyclically depend on each other. Whichever module gets imported first will just be ignored the second time the same use
statement appears.
That said, cyclical imports may cause a lot of trouble and should be discouraged if not prohibited in my eyes.
I think it is actually possible at the moment to have cyclical dependencies of modules on each other as long as the actual functions/function calls in them don't cyclically depend on each other.
If so, I couldn't manage to make it work. I was developing a new function, so nothing else depended on it, but depending on module load order either lists or strings module threw an error due to an unrecognized name the first time the respective module used a function from the other.
I am writing some more utility functions for numbat, currently I'm working on str_split which splits a string into a list of strings based on a string pattern. I Would like to put this in the
core::strings
module as that fits it very well, but because I need thecore::lists
module and it already has a dependency on the former, this is not possible. I think it would be beneficial to either allow such cyclical dependencies or to document how such cases aught to be handled.I know F# disallows cyclical dependencies, so if we don't want to support it, maybe we could look to it for other approaches to handle such cases.