Define a set of functions with a macro

This isn’t going to return anything, perhaps you means Enum.map?

Perhaps you are right.
But it does not help to make it work.

In this variant (no matter .each or .map) it does defines functions, but does not pass type, spec & bits values to the definitions, so, we cannot do pattern matching on type parameter and use correct binary spec.

defmacro deftyped(call, do: block) do
    quote do
      [
        float64: {:float, 64},
        float32: {:float, 32},
        byte: {:integer, 8},
        int16: {:integer, 16},
        int32: {:integer, 32},
        int64: {:integer, 64}
      ]
      |> Enum.each(fn {type, {spec, bits}} ->
        def unquote(call), do: unquote(block)
      end)
    end
  end

Defining functions is a side-effect, so each is fine.

def isn’t called, but unquoted only, so its sideeffect won’t fire. So to my understanding we need to use map here to get the def into the hosting modules AST and then actually “run” it there in the new context.

I do see your point without the quoting though.

edit

Nevermind, I just realise we have the each inside the quoting, therefore my comment is irrelevant

My suggestion would be to avoid the macro for definitions altogether in favor of a simple type_and_size macro and then organize your codebase like this:

defmodule Matrex do
  # Functions that do not depend on the type

  def foo(...) do
  def bar(...) do
  def baz(...) do

  # Headers of functions that depend on the type

  @doc "..."
  def concatenate(matrex, foo)

  # Implementation of functions that depend on the type

  defmacrop type_and_size() do
    {type, size} = Module.get_attribute(__CALLER__.module, :type_and_size)
    quote do
      size(unquote(size))-unquote(type)()
    end
  end

  types = [
    float64: {:float, 64},
    float32: {:float, 32},
    byte: {:integer, 8},
    int16: {:integer, 16},
    int32: {:integer, 32},
    int64: {:integer, 6}}
  ]

  for {guard, type_and_size} <- types do
    @guard guard
    @type_and_size type_and_size

    def concatenate(%Matrex{type: @guard}) do
      <<x,y,z::type_and_size()>>
    end
  end
end

This way tou will define one clause per type, where you guard on the type with the @guard attribute, and use the type_and_size() macro to inject the proper binary modifiers.

You should also consider not defining :float64 types (and similar). Instead you can simply pass the type/size around. So you have {:float, 64} instead of :float64. This allows two other implementations. The first one simply removes the @guard part and matches on @type_and_size:

  defmacrop type_and_size() do
    {type, size} = Module.get_attribute(__CALLER__.module, :type_and_size)
    quote do
      size(unquote(size))-unquote(type)()
    end
  end

  types = [
    {:float, 64},
    {:float, 32},
    {:integer, 8},
    {:integer, 16},
    {:integer, 32},
    {:integer, 6}}
  ]

  for type_and_size <- types do
    @type_and_size type_and_size

    def concatenate(%Matrex{type: @type_and_size}) do
      <<x,y,z::type_and_size()>>
    end
  end

However, we can also use this approach to define only two clauses, one for integer and another for floats instead of one clause per type x size pair. It would look something like this:

  defmacrop type_and_size(size) do
    type = Module.get_attribute(__CALLER__.module, :matrix_type)
    quote do
      size(unquote(size))-unquote(type)()
    end
  end

  for type <- [:float, :integer] do
    @matrix_type type

    def concatenate(%Matrex{type: {@matrix_type, size}}) do
      <<x,y,z::type_and_size(size)>>
    end
  end

This last approach will be easier on compilation time but it is likely slower in terms of runtime performance as you are giving the compiler less information when building/matching binaries. I would personally go with the earlier solutions unless you find yourself having to define many other types, such as int1, int4, etc.

Thanks, Jose!

For now I will stay with the first version, because using and atom :float64 will be more convenient for users, than using tuples. And it will also resemble them NumPy, if they are familiar.

Gradually most of these ‘typed’ functions will be converted to NIFs, I believe. So now I have to solve similar problem in the C language and then will be able to head towards first version of typed and shaped multi-dimensional matrices:)

Oh I read it as quoted def’s for some reason! ^.^;

Hmm, actually that is because it is (see the original post)… So doesn’t this hold true, that Enum.each wouldn’t do anything? So.. why would Enum.each work here when it is being quoted inside of it @josevalim ? o.O

Wait, I thought Enum.each was inside the quote but it was outside, haha. Yes, it has to be a map then.