lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Sat, Oct 16, 2010 at 06:38, steve donovan <> wrote:
> On Wed, Oct 13, 2010 at 3:24 PM, Norman Clarke <> wrote:
>> Your feedback would be very welcome!
> Continuing the discussion we were having on luarocks-l, I think
> writing tests is a great use case for Lua as a DSL, via some
> preprocessor such as the token-filter patch or Metalua. For instance,
> the example given above can be written like so using (e.g.) LuaMacro:
> context "A context" do
>  before do
>    -- setup
>  end
>  after do
>    -- tear down
>  end

I agree this is a more aesthetically pleasing syntax, and also much
easier to type. Somewhat surprisingly, it's also valid Lua, which
becomes more obvious if you read it like this:

context "Another nested context"
    test "Another test"
        assert_greater_than(2, 1)

Of course to interpret the code inside the "do" blocks as functions
you'd need to run it through some kind of filter, but it's a nice
benefit that it doesn't break syntax highlighting or other editor
functionality that wants valid Lua.

>  context "A nested context" do
>    test "A test" do
>      assert_not_equal("ham", "cheese")
>    end
>    context "Another nested context" do
>      test "Another test" do
>        assert_greater_than(2, 1)
>      end
>    end
> OK, this is no longer standard Lua, which _is_ an issue if this is
> application code. But (as lhf always points out) a token-filter Lua
> can be used as a compiler (like Metalua) which generates the code to
> be executed by the regular Lua executable.

What I really like about Shake is that it accomplishes this by using
Leg to change the code's semantics without changing its syntax, so it
also works on valid Lua, but doesn't depend on a patched interpreter.

> Here would be a typical launcher script for separate compile-run steps:
> name=$1
> tlua -lmacro $name.lua

Yikes, is there something in wide use already using the name "tlua"?
I'm using that for a project and should probably change it if that's
the case.

> The important thing about designing DSLs is knowing when to stop ;)

Haha! Very true.

Well, the good thing about Telescope at least is that it doesn't
really depend on any particular syntax. What gets fed into the test
runner is a table with the names of the contexts and the functions to
run. You can write a function to build that table from any syntax you
want, and Telescope will still run the tests and issue reports the
exact same way. That's how we were able to get Shake more or less up
and running in a couple hours. I imagine getting it to work with the
syntax you described above would be even easier.