Macro does not like module attribute?

Questions / Help
, ,
1

In file 1:

defmodule Utils.Struct do

  # this is for importing definitions when "use Utils.Struct" is called
  defmacro __using__(_opts) do
    quote do
      import Utils.Struct
    end
  end

  defmacro defstruct_module(struct_name, fields) do
    quote do
      defmodule unquote(struct_name) do
        use Utils.Access
        defstruct unquote(fields)
      end
    end
  end

end

In file 2:

defmodule Statistical.Generator do

use Utils.Struct

@in_files [:in_cause, :out_cause, :start]

defstruct_module(State, @in_files)

Breaks:

warning: undefined module attribute @in_files, please remove access to @in_files or explicitly set it before access
  <some file>: Statistical.Generator.State (module)


== Compilation error in file <some file> ==
** (ArgumentError) struct fields definition must be list, got: nil
    (elixir 1.14.4) lib/kernel/utils.ex:117: Kernel.Utils.defstruct/3

But this works - again file 2:

defmodule Statistical.Generator do

use Utils.Struct

@in_files [:in_cause, :out_cause, :start]
in_files = @in_files

defstruct_module(State, in_files)

By the way, if I use the variable approach instead of the module attribute, than the def blocks of the module in file 2 complain… can’t win? :sweat_smile:

Is this because the it inserts the module attribute verbatim as abstract syntax tree? Is there a construct/pattern to handle this case - like would a bind_quote help?

Thank you!

2

To use the module attributes in your macro, you’ll need to do it in __before_compile__/1.

Take a look at this upgrade of my library which was done precisely for the same reason
(see the difference between v0.2.0 and v0.1.0) - kudos and thanks to @kip

3

If I understand your code correctly it tries to find an attribute in the calling module and use it in the macro.

I think my scenario is a bit different - I’m trying to pass a value to the macro, and it’s not always a module attribute either. I typically call it like this:

defstruct_module(State, [:some, :fields])

If I understand what you’re doing, it might be possible to match for “module attribute” in a separate head for the same macro and then use Module.get_attribute/3 and call the other Macro head with it?

We tried Macro.expand(param, __CALLER__) and it remained nil.

If you meant something else, please let me know.

4

No, it’s the same case. My lib is also mostly taking lists of atom keys as such, but I needed it to support taking a module attribute as well, hence the change.

5

Correct. You could instead first unquote it in its actual scope:

    quote do
      fields = unquote(fields)
      defmodule unquote(struct_name) do
        use Utils.Access
        defstruct fields
      end
    end
2 Likes
6

Thank you both!

Let me preface this with the fact that I can live with adding an extra variable on top-level by hand if that’s easiest.

But I still want to follow up with you.

@josevalim - I tried your solution, and it works for the module atttribute case.

Another use case then has a different problem:

defstruct_module(Channel.Quality, [<... some fields ...>])
[...]
defstruct_module(Model.Params,   [channel:         %Channel.Quality{}])

Will result in:

== Compilation error in file lib/model.ex ==
** (CompileError) lib/model.ex:20: cannot access struct Channel.Quality, the struct was not yet defined or the struct is being accessed in the same context that defines it
    expanding struct: Channel.Quality.__struct__/1
    lib/model.ex:20: (file)
    expanding macro: Utils.Struct.defstruct_module/2
    lib/model.ex:20: (file)

I assume this is due to the fields list being expanded now outside the defmodule and compiled before that “inner module” was compiled yet?

The original version worked with that scenario where the list was given directly.

I tried bind_quoted but then I also need to use it on struct_name field and then aliases are expanded differently (and no longer include the name of any module defined one level higher).

It’s a tricky one… There’s always a scope where it doesn’t come together.

@DaAnalyst -

I know it’s on me / is my fault, but I’m looking at the diff of your project and I just can’t see how that pertains to my problem. My mind doesn’t make the connection.

7

If you look at my lib code, you’ll see that in its first version (0.1.0) it simply relied on the vanilla macros to expand the def assign_* and friends. The problem with that approach was that it could only take a list of atoms and not a module attribute (to which a list of atoms is assigned) because the module attribute was not resolvable at the time of the macro expansion. The __before_compile__/1 approach that was suggested by @kip solved this (as shown in the version 0.2.0) because at the time it expands it can resolve the module attributes, hence the necessary refactoring.