`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 <[email protected]> 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/22887a7e-a1b6-4ccc-98bf-69a5ad3551a5n%40googlegroups.com.
