Gain insights into metaprogramming in Elixir. Delve into macros and discover how to elevate your coding skills, creating powerful libraries with concise, efficient code.

_Metaprogramming Elixir by The Pragmatic Programmer_468 x 60 copy.png

elixir.tar.gz

elixir

elixir-testing

elixir-copy

Get introduced to the concept of metaprogramming. Learn how to level up your programming skills by discovering the full potential of the macro system in Elixir. Understand the ins and outs of metaprogramming at a fundamental level and write incredible libraries by doing more with less code.

Metaprogramming in Elixir

So DSLs are pretty cool, huh? It’s tempting to solve all kinds of problems this way, but be careful! Many problems that seem like a good fit for a DSL are often better served by standard functions. 

# The big three


Whenever trying to decide whether a DSL is a good fit, keep the following questions in mind:
1. Can the domain be expressed naturally by macros in Elixir’s syntax, such as HTML tags?
2. Would a DSL cause the caller to think more or less about how to solve their problem?
3. Should I require users of my library to have all kinds of code injected into their context?

The answers to these questions vary, and many times it’s a gray area. To help illustrate these points, let’s imagine a fictitious `Emailer` library that we would like to build. At first glance, the email domain can be expressed very simply by words like `from`, `to`, `subject`, or `send`. It seems an `email` library would meet the requirements of the first point, where macros can express the problem naturally.

![](/api/collection/10370001/5074130048647168/page/5436497165025280/image/5570672916430848)

# `Emailer` library as a DSL
With that thought, let’s imagine what our library could look like as a DSL:
```
defmodule UserWelcomeEmail do 
  use Emailer

  from "info@example.com" 
  reply_to "info@example.com" 
  subject "Welcome!"

  def deliver(to, body) do 
    send_email to: to, body: body
  end 
end

UserWelcomeEmail.deliver("user@example.com", "Hello there!")

```
Not too bad, right? Callers could use `Emailer` and have a DSL defined for wiring up email headers, such as `from`, `reply_to`, etc. This reads nicely, but consider the second question above: “Would this DSL cause the caller to think more or less about how to solve their problem?” For example, what if the caller adds custom extension headers, such as `X-SERVICE-ID`? The email spec supports arbitrary headers, so this suddenly puts our DSL into a snag. One quick solution is to support an optional headers function that the caller can implement to add custom headers:
```
defmodule UserWelcomeEmail do 
  use Emailer

  from "info@example.com" 
  reply_to "info@example.com" 
  subject "Welcome!"
  
  def headers do
    %{"X-SERVICE-ID" => "myservice"}
  end

  def deliver(to, body) do 
    send_email to: to, body: body
  end 
end
```

This works, but now the caller must know or look up which headers are supported by the DSL and when they need to define a headers map. Now, let’s consider an API without a DSL. It would simply require the caller to define a `headers` function that returns a map of all email headers they require.
```
defmodule UserWelcomeEmail do 
  use Emailer
  
  def headers do
    %{"from"  =>  "info@example.com" 
      "reply_to" => "info@example.com" 
      "subject" => "Welcome!"
      "X-SERVICE-ID" => "myservice"}

  def deliver(to, body) do 
    send_email to: to, body: body
  end 
end
```
## Do we need the DSL approach?
In this case, the non-DSL approach wins out. The usage is clear and still reads nicely without the need for a DSL.

The last point to consider when weighing the options for a DSL is whether a caller really needs a bunch of code injected into its module. Sometimes, the clear answer is yes, but other times having all kinds of macros and code injected into the module is less desirable for simple actions like sending an email. It can clash with user code and add complexity where functions would have been more appropriate.

## Conclusion
Based on this, the `Emailer` library would not make a good DSL. Explicit functions provide an easier-to-use API without the need to learn a special DSL just to send an email message. DSLs are a powerful tool, but think carefully whether they accurately solve the domain problem. They allow a simplified API for problem-solving, but sometimes this can become restrictive. Their use should be determined on a case-by-case basis, and it helps to ask ourselves those three questions every time we think DSLs might be a good choice.


Learn when to use DSL instead of standard functions. 

Introduction

The Language of Macros

Extending Elixir with Metaprogramming

Advanced Compile-Time Code Generation

Code Generation from Git API

How to Test Macros

Create an HTML Domain-Specific Language

With Great Power Comes Great Responsibility (and Fun!)

To DSL or Not to DSL?

The big three

`Emailer` library as a DSL