I've been thinking about lisp minilanguages again lately, and I'm wondering what are the benifits of them over, say, data structures/classes? As much as I've thought about it, I still won't feel comfortable until I've discussed this with someone who knows a bit more about lisp, and it never hurts to have more dicussions.

Quote:Original post by Roboguy
DSLs can actually be OO, if that's well suited to the problem it's trying to solve. They are used to make solving specific types problems easier.

Actually, I was referring more to the advantages of DSLs over using just plain data. Here's an old example that illustrates what I mean:

(defquest    (hero link)    (objective        (recover princess-zelda))    (difficulty hard))

vs.

quest = Quest(  hero="link",  objective="Zelda",  difficulty=HARD)

Where 'Quest', in this case, is a data structure (or class, if you prefer).

I'd also like to point out that this isn't meant to be flamebait (as Shannon suggests)--I really do want to know the advantages of DSLs. I've already read a lot about them, but I've found that actually talking to someone about it reveals a lot of information that otherwise wouldn't have been found.

Mini-languages allow you to expand the expressivity of data. For instance, let's say that a particular weapon does a certain number of points of damage. So you might have, in your datastructure, a line like Damage = 3. Now, if your RPG has the weapon do different amounts of damage to, say, small, medium, and large monsters, it might look like Damage = {Small = 5, Medium = 4, Large = 3}. But wait! Suppose this particular weapon deals an extra point of damage when you're attacking an ogre named Ed who likes onions? Now things get tricky, and the data structure format gets ugly. What's happening is that the format should be expressive enough to express what you want to express, yet (maybe) shouldn't need to be changed piecemeal to accomodate new types of weapons. So instead you have a line like Damage = function(monster) if monster.type == "ogre" and monster.name = "Ed" and monster.likes("onions") return 4 else return 3 end. Bingo: All the complexity you want, none that you don't want.

Also, suppose that that particular weapon is The Ed Sword. There are similar swords, such as the Ted sword and the Bill sword, which are meant for attacking other ogres with different names. You could have a separate entry for each and manually keep all of them updated together, or you could have your minilanguage produce multiple weapons, given a list of names.

That's the ideal. Of course, many consider Little Languages to be an antipattern in certain workflow situations. Think long and hard as to whether you actually need one. They can be difficult to understand, difficult to integrate into tools, and difficult to maintain when underlying engine structure changes.

Quote:Original post by Sneftel
They can be difficult to understand, difficult to integrate into tools

Strange... I often find myself making tools with the explicit purpose of interpreting some "little language" and producing some output resource file. :s (Of course, I suppose those languages are generally littler than the ones that can be produced by Lisping, unless you want to write a full-blown compiler...)

Quote:
a)what's a DSL?

Domain-Specific Language.

Quote:
b)isn't the advantage of the Lisp version is that code is data

Yes. Domain-Specific Languages can be created in lisp based on this concept (using macros). I'm not sure what you mean by this, though:

Quote:
, where as the "class" below has to be compiled to some form of binary or byte code?

Quote:Original post by Zahlman
Strange... I often find myself making tools with the explicit purpose of interpreting some "little language" and producing some output resource file. :s (Of course, I suppose those languages are generally littler than the ones that can be produced by Lisping, unless you want to write a full-blown compiler...)

I'm mostly referring to the tools which produce the LL code, rather than those which process it. Level editors, for example, where you're coding triggers. The problem is, triggers expressed as a simple, un-language-like set of data can be easily produced with GUI tools, represented with GUI tools, and linted. Once you get into LLs, though, the effect of an attribute cannot be reliably inferred from the code of the attribute. This can lead to a situation I've seen several times: a GUI which (bad) chokes on, or (semi-bad) ignores, any code outside of that conforming to a set of templates which it produces and can parse (think "go to level X" and "give item Y"). For everything else, you either edit the level file manually, or inject code using the keyboard in the level editor. And after you do either of these things, the editor basically folds its arms and refuses to lint your level or give you useful arrows showing the destination of manually coded doors.

Quote:
Mini-languages allow you to expand the expressivity of data.

How would this be better than custom file format?

Quote:
But wait! Suppose this particular weapon deals an extra point of damage when you're attacking an ogre named Ed who likes onions? Now things get tricky, and the data structure format gets ugly. What's happening is that the format should be expressive enough to express what you want to express, yet (maybe) shouldn't need to be changed piecemeal to accomodate new types of weapons. So instead you have a line like Damage = function(monster) if monster.type == "ogre" and monster.name = "Ed" and monster.likes("onions") return 4 else return 3 end. Bingo: All the complexity you want, none that you don't want.

I would think it would be easier to just use polymorphism, since that's what it looks like you're doing.

Quote:Original post by bytecoder

Quote:
Mini-languages allow you to expand the expressivity of data.

How would this be better than custom file format?

It's not really a question of format. Using your native language's parser saves you the trouble of writing your own parser, if you like. But a mini-language can be a custom file format.

Quote:
I would think it would be easier to just use polymorphism, since that's what it looks like you're doing.

That depends on what you mean by "use polymorphism".