I see. Great find. Back to the drawing board. On Mon, Jul 11, 2022 at 8:34 PM Zach Daniel <zachary.s.dan...@gmail.com> wrote:
> hm… I'm pretty sure that this issue exists for `defimpl` in the new code > that you've added. > > ``` > defmodule Foo.Bar.Baz <http://foo.bar.baz/> do > end > > alias Foo.Bar.Baz <http://foo.bar.baz/> > > defimpl Proto, for: Baz do > def foo(_thing), do: 10 > end > > ``` > will show an `unused alias Baz` warning. > > > On Mon, Jul 11, 2022 at 1:48 PM, Zach Daniel <zachary.s.dan...@gmail.com> > wrote: > >> Interesting…I'll do some spelunking and try to figure out why `defimpl` >> doesn't yield the same unused alias warnings that my code does then >> >> >> ``` >> defmodule Foo.Bar.Baz <http://foo.bar.baz/> do >> end >> >> alias Foo.Bar.Baz <http://foo.bar.baz/> >> >> defimpl Proto, for: Baz do >> def foo(_thing), do: 10 >> end >> ``` >> >> >> On Mon, Jul 11, 2022 at 1:42 PM, José Valim <jose.va...@dashbit.co> >> wrote: >> >>> In this case you pass lexical_tracker: nil indeed, that's what we do for >>> defimpl for now, although it is a private API for now. >>> >>> On Mon, Jul 11, 2022 at 7:08 PM Zach Daniel <zachary.s.dan...@gmail.com> >>> wrote: >>> >>>> So I tried out doing the same thing that you are currently doing in >>>> `expand_literal/2` and I've hit a snag. >>>> >>>> In the Ash DSL, there are some module references where we don't want to >>>> incur a runtime dependency *or* a compile time dependency. From what I can >>>> tell, the pattern of `expand_literal/2` still incurs runtime dependencies. >>>> In Ash, we have this code: >>>> >>>> ``` >>>> def expand_alias(ast, %Macro.Env{} = env) do >>>> Macro.prewalk(ast, fn >>>> {:__aliases__, _, _} = node -> >>>> Macro.expand(node, %{env | function: {:__ash_placeholder__, 0}}) >>>> >>>> other -> >>>> other >>>> end) >>>> end >>>> >>>> def expand_alias_no_require(ast, %Macro.Env{} = env) do >>>> Macro.prewalk(ast, fn >>>> {:__aliases__, _, _} = node -> >>>> Macro.expand(node, %{env | lexical_tracker: nil}) >>>> >>>> other -> >>>> other >>>> end) >>>> end >>>> ``` >>>> >>>> which models the difference between how we are currently doing things. >>>> The primary issue here is that the things using `expand_alias_no_require/2` >>>> currently are marked as unused alias, and from what I can tell >>>> `expand_literal/2` doesn't solve for that issue. >>>> On Monday, May 9, 2022 at 4:33:58 PM UTC-4 Zach Daniel wrote: >>>> >>>>> Awesome, thanks! >>>>> >>>>> >>>>> On Mon, May 09, 2022 at 4:10 PM, José Valim <jose....@dashbit.co> >>>>> wrote: >>>>> >>>>>> It should be added when I fix this: >>>>>> https://github.com/elixir-lang/elixir/issues/11706 :) >>>>>> >>>>>> On Mon, May 9, 2022 at 8:02 PM Zach Daniel < >>>>>> zachary.s.dan...@gmail.com> wrote: >>>>>> >>>>> That sounds perfect! Is there any place that I can see what that >>>>>>> public API will look like? I totally understand on being careful in that >>>>>>> regard. Since Ash DSLs are more like static configuration, there are a >>>>>>> few >>>>>>> places where this is acceptable, but we don't use it for every (or even >>>>>>> most) of the places where a module name might be. >>>>>>> >>>>>>> On Monday, May 9, 2022 at 2:00:11 PM UTC-4 José Valim wrote: >>>>>>> >>>>>>>> Btw, we will also have a public API on Elixir v1.14 for expanding >>>>>>>> literals, so the problem shall disappear altogether. However, you must >>>>>>>> be >>>>>>>> extremely careful: this should only be used if you indeed don't use it >>>>>>>> at >>>>>>>> compile time. >>>>>>>> >>>>>>>> On Mon, May 9, 2022 at 7:56 PM Zach Daniel <zachary....@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Also, I forgot to mention, it was @icecreamcohen on discord who >>>>>>>>> had the idea that redefining alias may work (although they didn't >>>>>>>>> really >>>>>>>>> condone it), don't want to take credit for anyone elses ideas though. >>>>>>>>> On Monday, May 9, 2022 at 1:53:50 PM UTC-4 Zach Daniel wrote: >>>>>>>>> >>>>>>>>>> This is something coming from a compile time optimization that >>>>>>>>>> Ash Framework does. >>>>>>>>>> >>>>>>>>>> In an Ash resource there is something called a change its >>>>>>>>>> basically like a plug but it operates on an Ash.Changeset >>>>>>>>>> >>>>>>>>>> So you might see something like this: >>>>>>>>>> ``` >>>>>>>>>> # in the resource >>>>>>>>>> actions do >>>>>>>>>> create :create_with_employee do >>>>>>>>>> change MyApp.CreateEmployee >>>>>>>>>> end >>>>>>>>>> end >>>>>>>>>> # the change module >>>>>>>>>> defmodule MyApp.CreateEmployee do >>>>>>>>>> use Ash.Resource.Change >>>>>>>>>> >>>>>>>>>> def change(changeset, _opts, _context) do >>>>>>>>>> Ash.Changeset.after_action(changeset, fn _changeset, result >>>>>>>>>> -> >>>>>>>>>> MyApp.Employee.create!(result.stuff, ...) >>>>>>>>>> end) >>>>>>>>>> end >>>>>>>>>> end >>>>>>>>>> >>>>>>>>>> Now, the change itself, when it comes to the resource, is simple >>>>>>>>>> static configuration. It cannot affect the compilation of the >>>>>>>>>> resource nor >>>>>>>>>> should any thing doing metaprogramming at compile time leverage the >>>>>>>>>> internals of that change >>>>>>>>>> >>>>>>>>>> Something that changes do often is refer to other related >>>>>>>>>> resources, like in this example case. So we drastically increase the >>>>>>>>>> surface area for transitive compile time dependencies >>>>>>>>>> >>>>>>>>>> Because a runtime dependency in one link becomes a compile time >>>>>>>>>> dependency when chained down the road. I.e I depend on the source >>>>>>>>>> resource, >>>>>>>>>> call it Post at compile time, and Post depends on Employee now at >>>>>>>>>> runtime, >>>>>>>>>> so I now depend on Employee at compile time. >>>>>>>>>> >>>>>>>>>> So to help people with their compile times, I've added some >>>>>>>>>> metaprogramming magic that does the following (only in very specific >>>>>>>>>> places >>>>>>>>>> for specific options) Macro.expand(node, %{env | lexical_tracker: >>>>>>>>>> nil}) and >>>>>>>>>> it works, no more unnecessary dependency. however, if you do this: >>>>>>>>>> ``` >>>>>>>>>> alias MyApp.CreateEmployee >>>>>>>>>> create :name do >>>>>>>>>> change CreateEmployee >>>>>>>>>> end >>>>>>>>>> ``` >>>>>>>>>> it yells at you for not using the alias, because I just disabled >>>>>>>>>> the thing that would inform the compiler that the alias was used >>>>>>>>>> >>>>>>>>>> I don't necessarily want to add back in those unnecessary compile >>>>>>>>>> time increases, so I'm looking for a way to detect that an alias had >>>>>>>>>> been >>>>>>>>>> used in these cases, and produce a compiler warning if you didn't >>>>>>>>>> add warn: >>>>>>>>>> false to the alias, that way you don't get a confusing "alias not >>>>>>>>>> used" >>>>>>>>>> error, you get (well, I guess you get both) an explanation of why >>>>>>>>>> the alias >>>>>>>>>> wasn't used and instructions to add warn: false to fix it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The options I have so far: >>>>>>>>>> >>>>>>>>>> 1. redefine `alias` and default to `warn: false` >>>>>>>>>> 2. redefine `alias` and track which ones have `warn: false` and >>>>>>>>>> print a warning if its used in one of these instances, so they can >>>>>>>>>> add it >>>>>>>>>> 3. if I detect that an alias is used, raise an error at compile >>>>>>>>>> time and say that aliases aren't supported here >>>>>>>>>> 4. get something in elixir core that allows explicit control to >>>>>>>>>> add something to an explicit list of "used aliases" >>>>>>>>>> >>>>>>>>>> Looking at the code for the lexical_tracker, it could be as >>>>>>>>>> simple as tracking a separate list of explicitly provided modules, >>>>>>>>>> or it >>>>>>>>>> could be a different mode of reference, i.e `:compile` `:runtime` or >>>>>>>>>> `:ignore`, that kind of thing. >>>>>>>>>> >>>>>>>>>> Also, if there is another way to accomplish the goal here I'm >>>>>>>>>> open to suggestions. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>> 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/f8e4ed44-f3a8-41cc-b82c-f6175ea461fdn%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/f8e4ed44-f3a8-41cc-b82c-f6175ea461fdn%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/a249ae72-fc35-4ff2-be69-567aa53ceb87n%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/a249ae72-fc35-4ff2-be69-567aa53ceb87n%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/CAGnRm4Lue_uJZdyChHFL_crrW6PVARBFUzm%3DvS5mmPGSSTFi9A%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Lue_uJZdyChHFL_crrW6PVARBFUzm%3DvS5mmPGSSTFi9A%40mail.gmail.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/136de6d8-f330-4135-8549-3ad70767a0efn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/136de6d8-f330-4135-8549-3ad70767a0efn%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/CAGnRm4JFV6XO-3QsYYTCyFDSCUx%2BZvk8WNWYF3-HTE-ksnuC3Q%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JFV6XO-3QsYYTCyFDSCUx%2BZvk8WNWYF3-HTE-ksnuC3Q%40mail.gmail.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/l5h31mlq.8b02b89a-781a-410a-9f22-50c707b5e571%40we.are.superhuman.com > <https://groups.google.com/d/msgid/elixir-lang-core/l5h31mlq.8b02b89a-781a-410a-9f22-50c707b5e571%40we.are.superhuman.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/CAGnRm4KPm3vhs2WB9moqAjshnsLgVe5vPxUm6c6QT3fngMbs9Q%40mail.gmail.com.
