Could we potentially do something only in the case that we reach this error? Like if a module fails to compile with an undefined variable error, we could attempt to compile it again with some metadata set that tells the compiler that it should check on remote calls if the module is available and the function is a module? Or do something like “go back up the stack” when an undefined error is received and only check the relevant remote calls at that point?
> On Apr 2, 2024, at 5:33 PM, José Valim <jose.va...@dashbit.co> wrote: > > Unfortunately this is hard. The simplest way to implement this would be by > checking on every remote call if the module is available and if the function > is macro, which would considerably slow down the compiler. The reason why we > have "require" is exactly so we don't need to pay this price. We could maybe > add some sort of tracking back to the compiler, but that would be easier said > than done. > > One alternative approach we could do is to, instead of failing to compile for > an undefined variable, we could warn, make it compile, and raise on said code > path at runtime. Then some later pass would find this is a macro and warn, > but now we are allowing a program that we are certain to fail, to compile and > move forward. > > Maybe there are other solutions but I can't think of anything else :( > > On Tue, Apr 2, 2024 at 8:40 PM Zach Daniel <zachary.s.dan...@gmail.com > <mailto:zachary.s.dan...@gmail.com>> wrote: >> Hey all! >> >> Something that happens very often to Ash users is forgetting to do something >> like `require Ash.Query`, and then doing something like this: >> >> ``` >> Ash.Query.filter(Resource, name == "fred") >> ``` >> >> Then, they get an error like `error: undefined variable "name"` >> >> What I'm wondering is if we can detect that they are in the arguments of a >> macro that exists but has not been required, and add a hint at the end of >> the message like "There is a macro called `Ash.Query.filter/2`, did you >> perhaps forget to `require Ash.Query`? >> >> I imagine this would help with folks using Ecto 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 >> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/cc96a81e-9126-4a9e-bb3a-9a7cd757986cn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/cc96a81e-9126-4a9e-bb3a-9a7cd757986cn%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 > <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KstcgzkppgLOTh8uGDkDjkVpWnh00GNT_%3DfmvNVP-yJQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KstcgzkppgLOTh8uGDkDjkVpWnh00GNT_%3DfmvNVP-yJQ%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/FC6E2267-5917-40DF-A3E7-ADFC8C372082%40gmail.com.
