Here is a working version of yours first way:

defmodule Example do
	# macro head used to avoid warnings and allows fast preview of default argument values
	# when field/2 is called the mepty list is passed as 3rd agument
	# since it does not matches first function clause it's goes to 2nd one
  defmacro field(_name, _type, _opts \\ [])

  # allows only a Keyword with single :do key and any value
  defmacro field(_name, _type, do: _block) do
    quote do
      IO.puts("With do … block notation")
    end
  end

  # allows any list including empty ones
  defmacro field(_name, _type, opts) when is_list(opts) do
    quote do
      IO.puts("Without do … block notation")
    end
  end
end

What you have missed here is function/macro head which you should use to handle default argument values in multi clause function/macro.

The second way is not possible, because there is a conflict for do … end block as it matches with both clauses. You can:

1. Name field macro with do … end differently (like ecto is doing)
2. Require passing empty list []
3. Handle @opts module attribute instead of function/macro argument

This is not possible. There are few reserved opts like :do or :else that you can use. You cannot combine for example: {a: 5] with do … end notation. :do and :else are part of keyword which is then passed as last macro argument.

macro_call :a, :b, c: 10 do
end
# is translated to:
macro_call(:b, :b, [c: 10], [do: …])

Also second way is not possible as macro_call(:a, :b) do … end may be seen as same macro_call(:a, :b, [], [do: …] as macro_call(:a, :b, [do: …]).

Yes, as you have tried my code with other case (i.e. field/4).

Why you can’t follow ecto’s way?

  guardedstruct do
    embeds :name, String.t(), enforce: true, derive: "sanitize(trim, upcase)" do
      field :title, String.t()
    end
  end

This way implementation is much simpler:

defmodule Example do
  # since we have a separate macro the `do … end` notation is always used
  # and therefore we don't even need function/macro head
  defmacro embeds(_name, _type, opts \\ [], do: block) when is_list(opts) do
  end

  # same here, both field/2 and field/3 are easy to pattern match in one clause
  defmacro field(_name, _type, opts \\ []) when is_list(opts) do
  end
end

embeds does not magically solves pattern matching.

Naming is up to you. I just used the existing one from ecto. Also not sure what you mean about style?

That’s a typical smoker excuse.

There is always another way. Not seeing it does not mean that it does not exist. Well … if you would watch a lot of anime then you would be sure about it and also meanwhile you would you would doubt if drugs are really illegal in Japan or if police really do anything about it.

There is no answer for it. Naming is something which may be specific to country, culture, community or even single companies or groups of people. Nobody would choose a naming for you. This is important to say as Elixir and Phoenix (which is called framework, but in fact it’s a library) does not force anything for you. While English language in development is at least in “West world” the most popular it does not mean you are forced to use it …

# in Polish "coś" means "something"
iex> coś = 5
5
iex> coś
5

Do you know kino hex package? The one José Valim announced? As he said he choose it, because in polish it means cinema. You are really free to name everything as you wish.

As a single person I can only recommend what I saw in past commonly, for example:

1. tree - often used around sql and self-referencing tables i.e. categories have many sub categories → category tree
2. nested - often used in forum questions when asking about nested lists or maps
3. has_many - ecto association type
4. many - short version
5. child - parent-child relations naming is often used in ecto’s schema
6. children - plural form
7. sub - similarily to nested, many times I saw people using words like sublist
8. struct or map - Elixir’s naming for data structures
9. sub_field
10. child_field