LÖVE

Does anyone here have experience creating domain-specific languages (DSL) within Lua? I am building one for a visual novel engine, which is itself part of a larger game project. This howto document shows what my DSL currently looks like:

https://github.com/ejmr/LNVL/blob/master/docs/Howto.md

I would be grateful if anyone has experience or links to resources online about DSLs in Lua, particularly with regard to game development.

Lua technically is a DSL, as it was born as one (when PETROBRAS hired TeCGraf at PUC-Rio to write a DSL for them). There are two interesting features of Lua's syntax that makes this possible:
1. You can pass strings or tables into functions without needing parenthesis
2. You can set metatables on tables to make it behave as a function

So this code is valid: The trick is as I said, metatables: This is basically how most OOP frameworks are constructed.

Inny wrote:1. You can pass strings or tables into functions without needing parenthesis
2. You can set metatables on tables to make it behave as a function

I would add a couple more to that list:
3. Functions are first-class language members. This means that you can define them and pass them as parameters when you need to.
4. The "environment" of a function is a table, and it's manipulable.

Functions are great for providing callbacks ("do this when this condition is matched"), and scopes. For example, in busted, the testing framework I currently use for Lua, most of the commands it provides accept a function:
Point [4] is a bit more advanced. In Lua 5.1 it's done with getfenv and setfenv, and you probably don't need it right away. It also changes in Lua 5.2.

Thanks Inny and kikito for the ideas. And the link to 'busted', useful-looking framework.

This is a really well documented and implemented project. Lua has a lot of potential as a platform for internal DSLs. In my opinion, this potential is not tapped often enough.

I have two ideas for this project. I'm not convinced that they are things that you should implement; however, I'm posting them because I think they are interesting.

Idea 1:

An alternative way to implement something like this would be to use coroutines. Instead of representing a scene as a sequence of expressions, you would represent it using a function. As with the current implementation, you would still be able to associate extra data, such as background images, with the scene by adding values into a table.

Example 4 might look something like this:
With this approach, I think it would be sensible to give the programmer two options for
scene transititions. One would be to call a function which sets up the scene and then executes its events.

Using this, you could organize your novel hierarchically as follows. The other option would be to set up a transition which occurs in a non-hierarchical manner after the current scene has finished executing. There would be pros and cons to this approach.

Pros:

-Debugger Friendly
-Scenes can be composed in a hierarchical fashion. (Actually this is an iffy pro—a screenwriter would never do this, so why would someone writing a visual novel?)
-Programmer can take advantage of constructs such as local variable definitions, if statements, and parameterized function calls

Cons:

-Less ability to reflect on the runtime data that represents scenes
-Function definitions are ugly in lua
-Probably a lot of other things that I didn't think of

Idea 2:

Another idea that I have is an alternative notation for monologues. If one chose to use the coroutine approach, it would be debugger friendly. If not, the notation *might* be slightly preferable, but I think the current notation works fine.

The new notation would look like this: SomeDude's call metamethod would take one string argument. However, the call metamethod would return SomeDude, allowing the programmer to supply additional lines for a monologue.

Finally, responding to your original question, I imagine that you have already read the paper Building Domain-Specific Languages over a Language Framework by the lua creators.

BTW. I can't run most of the examples because the image resources that they depend on do not seem to have been included.

Keep up the good work.

kclanc wrote:I have two ideas for this project. I'm not convinced that they are things that you should implement; however, I'm posting them because I think they are interesting….

Thank you for the ideas. I agree both are interesting, and worth considering. I would like to use co-routines to make debugging easier, as you mention, but I have not been able to find a way to make their use feel ‘pedestrian’ enough, for lack of a better term.

Finally, responding to your original question, I imagine that you have already read the paper Building Domain-Specific Languages over a Language Framework by the lua creators.

Not in many years, to the point where I had forgotten about it, heh. Thanks for the reminder.

BTW. I can't run most of the examples because the image resources that they depend on do not seem to have been included.

Ah true; I need to fix that eventually. The project is in lockstep development with another and is currently using art assets from that which I don’t want to permanently include. But at some point I will change them around to use some other assets, either something custom or public-domain.

Inny wrote:Lua technically is a DSL, as it was born as one (when PETROBRAS hired TeCGraf at PUC-Rio to write a DSL for them). There are
The trick is as I said, metatables:

Code: Select all

Room = setmetatable({}, {
  __call = function(original, created)
    -- manipulate the new room here
    return created
  end
})

In this case, you can simplify the table+metatable to just a function:

I've been playing around with Lua internal DSLs as well.

Take something like this:
Now assume your scenes are not going to be nested within one another. That is, you're only ever building one (the "context") at a time.

Now, instead of assigning the scene directly into a local, and function into a member variable of the scene, you can rewrite the above like this:
The scene function takes a string, creates a scene (the "context"), and stashes it away. The function is assigned to a global variable called 'script'. What you do is configure the environment when loading the DSL so that creating a global named 'script' checks that it is a function, and instead of creating a global it stores it in the context scene.

If you have additional functions besides 'script' per scene, you just give them different names. If you have simple properties, you can make them functions taking a string and configuring the context scene appropriately. So your scene could have setting 'outside' and time 'night'.

I've tried this and it makes for quite a readable DSL.

As for where your scenes get stashed, you can create global variables for them if they are uniquely named (they probably are), automatically in the scene creator function. Also remember, this "global" environment can still be unique to loading the DSL and so not actually trample the "real" global environment.

Using globals allows you to write a function that just uses variable NOT_GUILTY as a scene, instead of having to do something like getScene('NOT_GUILTY'). This works (even in the script function for the END scene) because when the function is compiled, the NOT_GUILTY scene doesn't have to have been made yet; the global reference is only resolved when the script function is called. Locals work too, but you probably don't need them.

Interesting idea, mlepage. Declaring a single function with the same name multiple times might be a little confusing from the perspective of default lua semantices, but it does use less syntax and is more readable.

Neat idea mlepage, and something that would have never crossed my mind. Many thanks for sharing.