Today I realized how powerful macros really are

Yeah, it sort of becomes a game of “is this valid Elixir syntax?”. Just quote expressions and have a look. For example, pow(x, 2) is fine, but in an equation dsl, it might be nice to write x^2. Valid syntax.

Yep, things that are special characters(of whom Elixir has very few) or attempting to use unary operators on two operands are the two things that are not possible. That basically means that # and ^ are out. Nearly all other things are fair game.

Macros are one of those items that are conceptually simple but hard to read and utilize in practice.

Each piece is simple in isolation. Macros are special functions that receive an AST and return an AST. quote/2 turns an expression into an AST. unquote/1 evaluates an expression and injects the results into a quoted expression (a.k.a. an AST fragment). And of course you have the concept of “hygiene” - variables created in a macro are private to that macro unless explicitly defined otherwise.

So again, the pieces are, on their own, easy to wrap your head around, but putting them together I’ve found difficult.

There are two great resources out there for learning Elixir’s metaprogramming capabilities - @chrismccord’s Metaprogramming Elixir and @sasajuric’s Understanding Elixir Macros mini-series. Head still hurts, and it will probably take two readings of each to have macros really sink in for me. (Oh, and of course the documentation on quote/2 is incredible).

I’m not sure what the point of my post is/was now.

So ^ is a bit weird.

quote do 1^2 end
** (SyntaxError) iex:1: syntax error before: '^'

quote do x^2 end
{:x, [], [{:^, [], [2]}]}

It would be ill-advised to include an operator with the gotcha that it cannot operate on a literal.

The problem here isn’t that ^ cannot operate on a literal (indeed, statements like ^2 are allowed), but that ^ is only defined as a unary operator (only taking a single input). For + and - this isn’t the case, as they have both a unary ( -2) and a binary variant ( 1 - 2).

Of course the obvious solution to the problem of operators is to use lisp which doesn’t have operators, and practically no reserved characters.

Limiting the amount of definable operators was a deliberate choice by José Valim. Operators are a nice and concise way to express things, but nobody knows what <<^ or <*> or =>= or $~! means when you first encounter them. In that way, they are very implicit. This is the reason that languages like Haskell are deemed hard to understand, because they are very operator-heavy.

I understand the choice @josevalim made here, but I do frequently miss this freedom in Elixir.

iex(server@snip.local)3> quote do lit 1,^ 2 end
{:lit, [], [1, {:^, [], [2]}]}

Eh, its ugly, but for a dsl it ‘might’ work depending on the purpose (probably not a math one)…

On a side-note, it would be freaking awesome to get some kind of defreadmacro or so, it gives you the binary/string input stream until some specified ending ‘thing’…

  # THE HORROR
  defreadmacro python(stream, env) do
    # blah
  end

  # elsewhere
  python~(
  a = 2+3
  print "blah"
  )~

Hmm, although I guess you could already do things like that…

defmacro myDSEL(input) when is_binary(input) do
  LISPToElixir.parse_to_ast(input)
end

def do_something() do
  myDSEL """
    (Enum.map (1 3.14 42) (:fn (x) (IO.inspect x)))
    """
end

/me wonders if someone is actually going to make that now…

Ah, lisp, in which every system is its own dialect of lisp