> > Anyway, the issue with this feature is exactly the same that appeared > during the defmodulep discussion: the only way to know if a function exists > in another module is by compiling that module and today the compiler does > not work under such assumptions.
It seems like mix compiles libraries in topological order (based on declared dependency relationships) so for modules provided by a dependency (or by Elixir itself) could it provide this? I guess such an approach would only provide the compiler errors for cases where you are attempting to call a function on a module from another library, not for cases where you are attempting to call a function from another module in the same project. It'd be an improvement in my book, though :). The best option to provide such features in the short-term is by doing a > post-compilation check. Post-compilation checks could also detect circular > dependencies which we would need to deprecate if we want to have such > features at compile time in the future. It's not clear to me why we have to deprecate circular module dependencies to support this feature as a post-compilation check. My mental model of Elixir's compiler is extremely limited, but here's an approach I'm imagining: - Before compilation, start an agent that tracks a map of functions to a list of call sites. - During compilation, at every remote function call site, add it to the agent so there is a record that `SomeModule.some_function/3` (or whatever) was called from a particular line of source code. - After compilation (as a post-compilation check), iterate over all remote function calls recorded in the agent. For each, attempt to load the named module, and see if the called function is defined on that module. If the module cannot be loaded or if the function is not defined, print an error. This scheme would allow circular module dependencies as we have now, assuming the post-compilation step does not run until the entire project has finished compilation. Circular project dependencies would not be allowed but from what I understand, they are already not allowed <https://github.com/elixir-lang/elixir/issues/4420>. Any reason such an approach wouldn't work with the existing compiler? Myron On Friday, May 6, 2016 at 11:00:56 AM UTC-7, José Valim wrote: > > But maybe my search-fu is just week (I searched on "remote function"). >> > > It was my bad, apparently it was over the elixir-lang-talk mailing list: > https://groups.google.com/forum/#!topic/elixir-lang-talk/Q3-bCnm6nxI > > I did not search earlier because I was not at my computer. :) > > Anyway, the issue with this feature is exactly the same that appeared > during the defmodulep discussion: the only way to know if a function exists > in another module is by compiling that module and today the compiler does > not work under such assumptions. It would be a medium-sized change to the > compiler and code with circular dependencies (arguable a bad thing anyway) > would no longer compile as it would run into a deadlock. So it is at least > a backwards incompatible change. > > The best option to provide such features in the short-term is by doing a > post-compilation check. Post-compilation checks could also detect circular > dependencies which we would need to deprecate if we want to have such > features at compile time in the future. > > It is definitely a topic I am interested on but it also plays against many > of the runtime features in the language. For example, if we imagine > protocols compile to something such as this: > > def to_string(binary) when is_binary(binary) do > String.Chars.Binary.to_string(binary) > end > > This could would no longer compile without adding a bit of indirection. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a9bfdc3b-6562-483c-b996-8551365f1f3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
