The best bet we can have at the moment is to add a runtime dependency indeed... why would a runtime dependency be bad in your case?
On Mon, Jul 11, 2022 at 8:37 PM José Valim <jose.va...@dashbit.co> wrote: > 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/CAGnRm4KoK-HHxniugy%2BjGdcUXKEF%2Bmv61XR4hmcHEEXAe2v2cw%40mail.gmail.com.
