Why do you want to remove the runtime dependency when, per your description:
> In Ash Framework, we have declarative ways to construct *runtime* behavior using behaviors. Emphasis mine. If, at any moment, you call any function from that module at runtime, you must not remove the compile time dependency. On Sun, Sep 11, 2022 at 8:52 PM Zach Daniel <zachary.s.dan...@gmail.com> wrote: > `expand_literal` removes the compile time dependency, but leaves a runtime > dependency when used inside of a module. > > What I'm trying to do is remove both the compile time dependency *and* the > runtime dependency, without requiring the use of `warn: false` on aliases. > > > > > On Sunday, September 11, 2022 at 2:31:42 PM UTC-4 José Valim wrote: > >> Sorry, I don't understand the proposal. You mentioned expand_literal, >> which already removes the compile-time dependency but keeps the remaining >> functionality such as warnings. Can you please expand? >> >> On Sun, Sep 11, 2022 at 7:57 PM Zach Daniel <zachary....@gmail.com> >> wrote: >> >>> For clarity, the dependency I'm talking about there is the dependency >>> from `MyApp.User` to `MyApp.User.Changes.HashPassword`. >>> On Sunday, September 11, 2022 at 1:55:51 PM UTC-4 Zach Daniel wrote: >>> >>>> In Ash Framework, we have declarative ways to construct runtime >>>> behavior using behaviors. So an Ash resource might look like this: >>>> >>>> >>>> ```elixir >>>> defmodule MyApp.User do >>>> use Ash.Resource >>>> >>>> alias MyApp.User.Changes.HashPassword >>>> >>>> attributes do >>>> uuid_primary_key :id >>>> .... >>>> end >>>> >>>> actions do >>>> create :register do >>>> change HashPassword >>>> end >>>> end >>>> end >>>> ``` >>>> >>>> However, by default, this would incur a compile time dependency. This >>>> compile time dependency is unnecessary, as we won't call any functions on >>>> this module or use it in any way until runtime. >>>> >>>> That optimization is well and good, but due to transitive compile time >>>> dependencies, we see some interesting behavior. Something you'd often see >>>> in a change module is things like pattern matching on other resources, or >>>> the resource in question in function heads. Resources are meant to be >>>> introspectable at compile time, and so this runtime dependency on a change, >>>> with a compile time dependency on a resource, incurs a transitive compile >>>> time dependency. This problem multiplies over time, and causes users to >>>> have to do things solely to optimize compile times, like only use map >>>> pattern matches instead of struct pattern matches. >>>> >>>> So what we do is we actually disable the lexical tracker when accepting >>>> certain parts of the DSL. This prevents *any* dependency. Naturally, at >>>> compile time you are no longer safe to call a resource's change module as >>>> changes in that module won't cause recompiles, but that was never a thing >>>> you should have done in the first place so I'm not worried about that. >>>> >>>> This leads us to the primary issue: disabling the lexical tracker when >>>> expanding aliases also causes warnings about unused aliases, even though >>>> they *are* used. I believe I've brought this issue up before and we were >>>> hoping that the feature introduced in 1.14 for `defimpl` would help, but >>>> that only helps prevent compile time issues, which is something I had >>>> already solved for in the same way it was solved for 1.14. I've laid it all >>>> out to help clarify exactly *why* I need it so perhaps someone can point me >>>> in a better direction. >>>> >>>> The simplest thing that could help: >>>> >>>> A way to tell the lexical tracker that an alias has just been >>>> referenced without inducing any kind of compile or runtime dependency. The >>>> idea is to just prevent it from warning about the alias. >>>> >>>> I'm open to other solutions as well. >>>> >>> -- >>> 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 elixir-lang-co...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/54627973-7b74-47d7-9e35-4270621e6c91n%40googlegroups.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/54627973-7b74-47d7-9e35-4270621e6c91n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/22887a7e-a1b6-4ccc-98bf-69a5ad3551a5n%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/22887a7e-a1b6-4ccc-98bf-69a5ad3551a5n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KzdUY5V1c9sRM3VpKifkP34tn97N-feo%2BRzd47WKjA7A%40mail.gmail.com.
