Sounds good! I’ll open one now. I’m also happy to investigate adding this, but will need a nudge as to where to start looking. Not high priority, but I think will be a great quality of life improvement for users.
> On Apr 2, 2024, at 5:40 PM, José Valim <jose.va...@dashbit.co> wrote: > > We could try that. Please open up an issue so we don't forget about it. :) > > On Tue, Apr 2, 2024 at 11:36 PM Zach Daniel <zachary.s.dan...@gmail.com > <mailto:zachary.s.dan...@gmail.com>> wrote: >> 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 >>> <mailto: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 >> <mailto: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 >> >> <https://groups.google.com/d/msgid/elixir-lang-core/FC6E2267-5917-40DF-A3E7-ADFC8C372082%40gmail.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/CAGnRm4KWJw8WChR-5vkvTAPVoxo6P2Kdx9bDH8s2%2BMLAMaU3hw%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KWJw8WChR-5vkvTAPVoxo6P2Kdx9bDH8s2%2BMLAMaU3hw%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/AD11856C-FAA0-4FE8-812D-C14B0FD6969B%40gmail.com.
