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.s.dan...@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-core+unsubscr...@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/CAGnRm4JDE%3DQ7zXP%3DNH36TZY4%2BGe1%3DuQa-qwCEF5-jczmFKcdkQ%40mail.gmail.com.
