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 <[email protected]> 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 <[email protected]>
>> 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 <[email protected]>
>>>> 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 [email protected].
>>>>>
>>>> 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 [email protected].
>>
>>
>>> 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 [email protected].
>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/136de6d8-f330-4135-8549-3ad70767a0efn%40googlegroups.com.
