DSL::Maker

require 'dsl/maker'

Car = Struct.new(:maker, :engine)
Engine = Struct.new(:is_hemi)
Truck = Struct.new(:maker, :engine, :towing)

class Vehicle::DSL < DSL::Maker
  dsl_engine = generate_dsl({
    :hemi => Boolean,
  }) do
    Engine.new(hemi)
  end

  add_entrypoint(:car, {
    :maker => String,
    :engine => dsl_engine,
  }) do |*args|
    default(maker, args, 0)
    Car.new(maker, engine)
  end

  add_entrypoint(:truck, {
    :maker => String,
    :towing => Integer,
    :engine => dsl_engine,
  }) do |*args|
    default(maker, args, 0)
    Truck.new(maker, engine, towing)
  end

  add_verification(:car) do |item|
    return "Cars need engines" unless item.engine
  end
  add_verification(:truck) do |item|
    return "Trucks need engines" unless item.engine
    return "Trucks aren't wimps" unless item.towing > 1000
  end
end

Then, use it as so:

#!/usr/bin/env ruby

require 'vehicle/dsl'

filename = ARGV.shift || raise 'No filename provided.'

# This raises the error
vehicles = Vehicle::DSL.parse_dsl(
  IO.read(filename),
)

with a file that could look like:

car do
  make 'Honda Civic'
  engine {
    hemi no
  }
end

truck 'Ford F-150' do
  engine {
    hemi On
  }
end

Writing single-level Ruby-like DSLs is really easy. Ruby practically builds them for you with a little meta-programming. Docile makes it ridiculously easy and there are nearly a dozen other modules to do so.

Unfortunately, writing multi-level DSLs becomes repetitive and overly complex. Which is dumb. Multi-level DSLs are where the sweetness lives. We write DSLs in order to make things simpler for ourselves, particularly when we want to have less-experienced individuals able to make changes because they have the business or domain knowledge. Limiting everything to single-level DSLs makes no sense.

DSL::Maker provides a quasi-DSL-like structure that allows you to easily build multi-level DSLs and handle the output.

In its documentation, Docile has a DSL that builds pizza. An example would look like:

@sauce_level = :extra

pizza do
  cheese
  pepperoni
  sauce @sauce_level
end
#=> #<Pizza:0x00001009dc398 @cheese=true, @pepperoni=true, @bacon=false, @sauce=:extra>

The PizzaBuilder code (via Docile) looks like:

Pizza = Struct.new(:cheese, :pepperoni, :bacon, :sauce)

class PizzaBuilder
  def cheese(v=true); @cheese = v; self; end
  def pepperoni(v=true); @pepperoni = v; self; end
  def bacon(v=true); @bacon = v; self; end
  def sauce(v=nil); @sauce = v; self; end
  def build
    Pizza.new(!!@cheese, !!@pepperoni, !!@bacon, @sauce)
  end
end

But, this doesn't actually implement the DSL. That is left for another snippet:

def pizza(&block)
  Docile.dsl_eval(PizzaBuilder.new, &block).build
end

And it's not quite clear where to actually put this code so that you can ship this DSL like Chef or Sinatra.

You would implement the same DSL using DSL::Maker as so:

class PizzaBuilder < DSL::Maker
  add_entrypoint(:pizza, {
    :cheese => Boolean,
    :pepperoni => Boolean,
    :bacon => Boolean,
    :sauce => String,
  }) do
    Pizza.new(cheese, pepperoni, bacon, sauce)
  end
end

pizzas = PizzaBuilder.parse_dsl("
  pizza {
    cheese yes
    pepperoni Yes
    bacon On
    sauce 'extra'
  }
")

Now, you accept the strings (possibly from IO.read()) and magically get the result of your DSL.

(The PizzaBuilder is used in the test suite in spec/single_level_spec.rb.)

So far, this isn't that impressive - slightly better type coercion and a method for handling the parsing of a string isn't much to crow about.

Person = Struct.new(:name, :mother, :father)

class FamilyTree < DSL::Maker
  add_entrypoint(:person, {
    :name => String,
    :mother => generate_dsl({
      :name => String,
    }) do
      Person.new(name, nil, nil)
    end,
    :father => generate_dsl({
      :name => String,
    }) do
      Person.new(name, nil, nil)
    end,
  }) do
    Person.new(name, mother, father)
  end
end

people = FamilyTree.parse_dsl("
  person {
    name 'John Smith'
    mother {
      name 'Mary Smith'
    }
    father {
      name 'Tom Smith'
    }
  }
")
john_smith = people[0]

Pretty easy. We can even refactor that a bit and end up with:

class FamilyTree < DSL::Maker
  parent = generate_dsl({
    :name => String,
  }) do
    Person.new(name)
  end

  add_entrypoint(:person, {
    :name => String,
    :mother => parent,
    :father => parent,
  }) do
    Person.new(name, mother, father)
  end
end

There's no limit to the number of levels you can go define.

We can improve the family tree DSL a bit by handling arguments. An example works best to explain.

Person = Struct.new(:name, :age, :mother, :father)
class FamilyTreeDSL < DSL::Maker
  parent = generate_dsl({
    :name => String,
    :age  => String,
  }) do |*args|
    default(:name, args)
    Person.new(name, age)
  end

  add_entrypoint(:person, {
    :name => String,
    :age  => String,
    :mother => parent,
    :father => parent,
  }) do |*args|
    default('name', args, 0)
    Person.new(name, age, mother, father)
  end
end

people = FamilyTreeDSL.parse_dsl("
  person 'John Smith' do
    age 20
    mother 'Mary Smith' do
      age 50
    end
    father {
      name 'Tom Smith'
      age 49
    }
  end
")
john_smith = people[0]

The result is exactly the same as before.

We're making an artificial distinction between person and parent in the FamilyTreeDSL example above. Really, we want to say "A person can have a mother and a father and those are also persons." So, let's say that.

Person = Struct.new(:name, :age, :mother, :father)

class FamilyTreeDSL < DSL::Maker
  person_dsl = add_entrypoint(:person, {
    :name => String,
    :age  => String,
  }) do |*args|
    default(:name, args)
    Person.new(name, age mother, father)
  end

  build_dsl_element(person_dsl, :mother, person_dsl)
  build_dsl_element(person_dsl, :father, person_dsl)
end

Now, we can handle an arbitrarily-deep family tree. This is the DSL used in the multi-level spec tests.

You'll note we've been receiving an Array from parse_dsl(). This is because DSL::Maker automagically handles files with multiple entries. Chef's recipe files have many entries of different types in them. It doesn't do you any good if you can't do the same thing.

Car = Struct.new(:make, :model)
Truck = Struct.new(:make, :model)

class VehicleDSL < DSL::Maker
  add_entrypoint(:car, {
    :make => String,
    :model => String,
  }) {
    Car.new(make, model)
  }

  add_entrypoint(:truck, {
    :make => String,
    :model => String,
  }) {
    Truck.new(make, model)
  }
end

vehicles = VehicleDSL.parse_dsl("
  car {
    make 'Honda'
    model 'Civic'
  }

  truck {
    make 'Ford'
    model 'F150'
  }
")

vehicles is an Array with a Car and a Truck in it, in that order. If your DSL snippet has only one item, you get back an Array with just that item. If it has multiple items, you get back an Array with everything in the right order.

DSL::Maker provides seven class methods - five for constructing your DSL and two for parsing your DSL.

• add_entrypoint(Symbol, Hash={}, Block)

This is used in defining your DSL class to create an entrypoint - the highest level of your DSL. add_entrypoint() will create the right class methods for Docile to use when parse_dsl() is called. It will also invoke generate_dsl() with the Hash you give it to create the parsing.

• entrypoint(Symbol)

This returns the DSL defined by a previous call to add_entrypoint().

This is primarily useful if you want to take a DSL class and use it within another DSL class.

• generate_dsl(Hash={}, Block)

This is used in defining your DSL to describe the innards - the guts that actually have meaning. Once this level has been completed, the Block will be called and the return value provided back to the name.

• build_dsl_element(Class, String, Type)

This is normally called by generate_dsl() to actually construct the DSL element. It is provided for you so that you can create recursive DSL definitions. Look at the tests in spec/multi_level_spec.rb for an example of this.

• add_type(Object, Block)

This is used to create type coercions that are used when defining your DSL. These are treated at the same level as the default type coercions described below.

This creates global type coercions that are available to every DSL definition.

• add_helper(Symbol, Block)

This is used to create helper methods (similar to default, described below) that are used within the DSL.

This creates global helpers that are available at every level of your DSLs.

• parse_dsl(String) / execute_dsl(&block)

You call this on your DSL class when you're ready to invoke your DSL. It will return an array containing whatever the block provided to add_entrypoint() returns.

It returns an array for the case of multiple DSL entrypoints (for example, a normal Chef recipe). The array will contain the values in the order they were encountered.

There are five pre-defined standard type coercions available for generate_dsl():

Standard coercions: * Any - This takes whatever you give it and returns it back. * String - This takes whatever you give it and returns the string within it. * Integer - This takes whatever you give it and returns the integer within it. * Boolean - This takes whatever you give it and returns the truthiness of it. * Hash - This takes a block and returns a Hash of the method calls.

You can add additional standard type coercions using add_type() as described above.

There are also three special type coercions that are not creatable with add_type() because they do special manipulations within DSL::Maker.

Special coercions: * generate_dsl() - This descends into another level of DSL. * ArrayOf[] - This creates an array coerced as the . Successive invocations are concatenated. can be a DSL. * AliasOf() - this creates an additional name that is synonomous with the item. You can use either this name or .

These are special-cased within build_dsl_element().

There is one pre-defined helper.

• default(String, Array, Integer=0)

This takes a method name and the args provided to the block. It then ensures that the method defaults to the value in the args at the optional third argument.

You can add additional helpers using add_helper() as described above.

$ gem install dsl_maker

• Add support for generating useful errors (ideally with line numbers ... ?)
• Add support for auto-generating documentation
• Add default block that returns a Struct-of-Structs named after entrypoints
• Add example of binary to execute a DSL
• DSL for DSL construction
• Add "include" helper that loads another file and continues the execution
  • Should provide useful directory searching

• Source
• Documentation
• Bug Tracker

Works on all ruby versions since 1.9.3, or so Travis CI tells us.

• Fork the project on GitHub.
• Setup your development environment with: gem install bundler; bundle install
• Make your feature addition or bug fix in a branch.
  • I will only accept PRs from branches, never master.
• Add tests for it. This is important so I don't break it in a future version unintentionally. Plus, I maintain 100% code coverage.
• Commit.
• Send me a pull request.
  • I will only accept PRs from branches, never master.

Copyright (c) 2015 Rob Kinyon