Back to General and Gameplay Programming

lisp minilanguages

General and Gameplay Programming Programming

Started by bytecoder December 19, 2005 09:17 PM

24 comments, last by bytecoder 18 years, 3 months ago

bytecoder

100

Author

December 20, 2005 05:49 PM

Quote:
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.

Correct me if I'm wrong, but isn't expressiveness directly tied to format? Oh, and I'm talking about DSLs in lisp using macros, to clarify :)

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

As in function pointers/virtual functions. Now that I look at it, that doesn't seem to matter. I'm not sure how the example you give is related to lisp DSLs, though.

Sneftel

1,788

December 20, 2005 05:58 PM

Quote:Original post by bytecoder
Correct me if I'm wrong, but isn't expressiveness directly tied to format?

Nah, not really. Your format is equally expressive whether it ends statements with semicolons or carriage returns. The important part is whether the format supports language-like features--conditionals, loops, things of that sort.

Quote:
As in function pointers/virtual functions. Now that I look at it, that doesn't seem to matter. I'm not sure how the example you give is related to lisp DSLs, though.

A DSL allows you to add the Ed Sword and its brothers to your world in a natural manner which doesn't require you to change the underlying format, the underlying parser, or the underlying engine structure. To get equivalent behavior would require you to change two or three of these things, and to spread your desired functionality across different modules.

bytecoder

100

Author

December 20, 2005 06:09 PM

Quote:
Nah, not really. Your format is equally expressive whether it ends statements with semicolons or carriage returns. The important part is whether the format supports language-like features--conditionals, loops, things of that sort.

Ok, I see.

Quote:

A DSL allows you to add the Ed Sword and its brothers to your world in a natural manner which doesn't require you to change the underlying format, the underlying parser, or the underlying engine structure. To get equivalent behavior would require you to change two or three of these things, and to spread your desired functionality across different modules.

I'm not sure I understand. If you didn't design the DSL with that in mind, you'd have to change it, just as you would if you didn't design the data structures with that in mind.

Extrarius

1,412

December 20, 2005 06:10 PM

Quote:Original post by Sneftel
[...]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.

I think the reason editors usually can't handle custom script well is that IME most game designers (whether professional or amateur) don't bother with reading existing material on something before they attempt to implement it, excepting graphics to some degree. If a person read 'The Dragon Book'(Compilers: Principles, Techniques, and Tools ISBN: 0201100886) before trying to implement a DSL (in a not-highest-level language, or something more appropriate for doing so in a Lisp-like), I think they would have no trouble making the editor itself work with the 'Real Script' and reserve the 'GUI Scripter' solely for easing the task of generating commonly-used patterns.

"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk

Sneftel

1,788

December 20, 2005 06:16 PM

Quote:Original post by bytecoder
I'm not sure I understand. If you didn't design the DSL with that in mind, you'd have to change it, just as you would if you didn't design the data structures with that in mind.

To some extent, yeah. In this situation, you need to design with the thought that the damage done by a weapon might depend on the monster involved. But that's a pretty logical assumption in the first place, much more logical than assuming that a weapon might need to care about onions.

Here's another example: A weapon which only does damage to monsters whose armor class is a prime number. Trivial to implement using a DSL; requires a "OnlyDoesDamageToPrimeArmorClasses" flag otherwise.

Alpha_ProgDes

6,963

December 20, 2005 06:29 PM

Quote:Original post by bytecoder
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?

sorry i misunderstood. i thought that was the representation of a C++ class. discussion over my head. don't mind me.

Beginner in Game Development? Read here. And read here.

bytecoder

100

Author

December 20, 2005 06:31 PM

Quote:
Here's another example: A weapon which only does damage to monsters whose armor class is a prime number. Trivial to implement using a DSL; requires a "OnlyDoesDamageToPrimeArmorClasses" flag otherwise.

In this situation, it really makes more sense to consider 'damage' as a separate entity. For example, such a situation could be handled like this:

data DamageExclude:  exlude_func:callable  damage:inttype DamageNormal = inttype Damage = DamageNormal | DamageExcludeClass

Sneftel

1,788

December 20, 2005 06:49 PM

Quote:Original post by bytecoder
In this situation, it really makes more sense to consider 'damage' as a separate entity.

I don't know that I'd agree with that; a level designer would be unlikely to consider a weapon's damage as a separate object from the weapon itself.

bytecoder

100

Author

December 20, 2005 06:51 PM

Quote:Original post by Sneftel
Quote:Original post by bytecoder
In this situation, it really makes more sense to consider 'damage' as a separate entity.

I don't know that I'd agree with that; a level designer would be unlikely to consider a weapon's damage as a separate object from the weapon itself.

I didn't mean that literally. I just figured it would help, as you seemed to be merging the damage type with the overall structure containing it.

Anonymous

December 20, 2005 06:57 PM

are there implementation's of such a data+minilanguage system?

are python/lua also count?

rob

lisp minilanguages

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

lisp minilanguages

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines