Sorry, correction: If, at any moment, you call any function from that module at runtime, you must not remove the *runtime* time dependency.
On Sun, Sep 11, 2022 at 8:55 PM José Valim <jose.va...@dashbit.co> wrote: > 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/CAGnRm4%2BVkL%2B1V7LTDVyzhCqcNWrmHFPoWx2Fp916Ur%2ByL%2BiVBA%40mail.gmail.com.
