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. daniel@ gmail. com > ( 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 ( https://github.com/elixir-lang/elixir/issues/11706 ) :) >>>> >>>> >>>> >>> >>> >>>> On Mon, May 9, 2022 at 8:02 PM Zach Daniel < zachary. s. daniel@ 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+unsubscribe@ 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+unsubscribe@ 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+unsubscribe@ googlegroups. com ( >> 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+unsubscribe@ googlegroups. com ( > 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/l5h1f5km.75ac99cf-59f8-4f7a-af7c-1bcb2f532d96%40we.are.superhuman.com.