Getting the @type module attribute

Hi all,

I’ve been playing with Specify lately and I’m trying to get the @type module attribute like the @doc one, so as to link to that type in my documentation.

Configuration looks like this:

  Specify.defconfig do
    @doc "there are no floors for me to sweep"

    @type floors_to_sweep :: non_neg_integer()

    field :floors_to_sweep, default: 0
  end

Trying to get the @type module attribute always results in a nil value:

        field_documentation = Module.delete_attribute(__MODULE__, :doc)
        IO.inspect(Module.delete_attribute(__MODULE__, :type))

The :doc is retrieved, but not the :type module attribute.

I suspect the @type is processed in a particular way. Is there any way to retrieve it?

Cheers

1 Like

Yeah, you can’t get @type, @spec, @callback and friends because they have special semantics. Usually, what is stored in a module attribute is evaluated, if you do @foo 1 + 1, the value of @foo is the result of 1 + 1. For typespecs, we actually receive an AST that we process, and returning that would leak some implementation details.

4 Likes

Interesting use case!

Currently, when you add @type-annotations inside the defconfig, they will end up being shown in the documentation just as if they were written outside of the defconfig.
So t YourModule.floors_to_sweep would work in IEx, and in the compiled HTML documentation, the type would also be listed.

If you want to fully link to a type, what about writing a parser function and adding a @spec to that one? The field documentation will link to its parser function’s documentation, and in that way you can keep the semantics together. (The other advantage is that you can re-use the same type/parser for multiple fields).

Thanks for your answers.

@Qqwy: not sure to understand and if it’s the same use case :slight_smile: . Mine is mainly about documenting hundreds (if not more) configuration options including many callbacks with most of the time different signatures, and linking between them (config option <-> type), and also to help dialyzer with detecting type errors. Nice lib by the way!

1 Like

I think this part is already covered by the existing functionality. Every module that uses defconfig will have, for every field in the documentation, the following part in their docs:

Example here.

This is indeed not something that Specify currently helps you with. It definitely would be interesting to automate the generation of a ‘config typespec’ in some way. Maybe the field types can be inferred from the parser function’s spec, and we can then define a type for the config struct as a whole. :thinking:

Thanks! :blush:

1 Like

I’ve tried it and it’s somehow difficult to generate some specs because of the special syntaxes of @type and @spec (::, etc.). See also: Dynamically generate typespecs from module attribute list

I’m fairly certain this is what Code.Typespec is meant to be used for.
We could (as long as the parser function is readable as an invocation of a certain MFA) call Code.Typespec.fetch_specs(module), find the appropriate function’s spec in the response, and then use Code.Typespec.spec_to_quoted to turn it back into Elixir AST, which, assuming that it has the format some_fun(maybe, some, arguments) :: {:ok, result_type} | {:error, problem} means that we should be able to extract the result_type from here.
The one thing I haven’t figured out yet is how to disambugate remote types from local and built-in ones.

1 Like

I’m now trying to get the @moduledoc module attribute in a __using__ macro but in:

      {line_number, existing_moduledoc} =
        Module.delete_attribute(__MODULE__, :moduledoc) || {0, ""}

      Module.put_attribute(
        __MODULE__,
        :moduledoc,
        {line_number, existing_moduledoc <> additional_doc})

Module.delete_attribute/2 always returns nil (although the @moduledoc is set) and Module.put_attribute/3 doesn’t set it (nothing in generated doc).

Is there an exception with @moduledoc? I suspect it is not set yet when calling Module.delete_attribute/2. Also Module.put_attribute/3is later erased by the plain @moduledoc (I’ve tested it - no @moduledoc in the target module results in additional_doc being displayed).