----
I'd like to see somone post a couple of brief examples of things that were well-suited to Lisp (and would be much more difficult in C) - anyone have anything handy?
----
One of the things that Lisp/Scheme is good at is as a tool for creating so-called "little languages" - miniature programming languages that are specific to a single problem domain.
Consider, for example, a computer game that had a "modding" API, allowing players to create their own levels and missions. The API would need to provide, amongst other things, a mechanism by which events could be trapped and bound to actions.
A Lisp/Scheme programmer might decide to tackle this problem by defining a little language that understood the concepts of events and actions.
For example, the "language" could provide a set of primitive events like this:
(then (display "The reactor is going critical!")
(do-nothing 10)
(play-sound whine)
(do-nothing 5)
(play-sound explosion)
(display "The reactor has been destroyed"))
Putting all this together, we could bind actions to events in the following way:
All that remains is to create a compiler for this language that will translate these expressions into a lower-level form suitable for use in the game engine. E.g. the compiler could output C code suitable for inclusion in a DLL.
Slashdot Mirror
----
... <eventn>)
... <eventn>)
... <actionn>)
I'd like to see somone post a couple of brief examples of things that were well-suited to Lisp (and would be much more difficult in C) - anyone have anything handy?
----
One of the things that Lisp/Scheme is good at is as a tool for creating so-called "little languages" - miniature programming languages that are specific to a single problem domain.
Consider, for example, a computer game that had a "modding" API, allowing players to create their own levels and missions. The API would need to provide, amongst other things, a mechanism by which events could be trapped and bound to actions.
A Lisp/Scheme programmer might decide to tackle this problem by defining a little language that understood the concepts of events and actions.
For example, the "language" could provide a set of primitive events like this:
(item-taken <item>)
(item-destroyed <item>)
(item-activated <item>)
(item-proximity <item>)
(and <event1> <event2>
(or <event1> <event2>
(not <event>)
Using these primitives, we could trap more complex events such as:
(and (item-taken documents)
(item-destroyed generator)
(or (item-activated homing-beacon)
(item-activated cable-car)))
There would also be a list of primitive actions:
(play-sound <clipname>)
(display <string>)
(restart-level)
(skip-to-next-level)
(do-nothing <seconds>)
(activate <object>)
(destroy <object>)
(then <action1> <action2>
Compound actions could be specified like so:
(then (display "The reactor is going critical!")
(do-nothing 10)
(play-sound whine)
(do-nothing 5)
(play-sound explosion)
(display "The reactor has been destroyed"))
Putting all this together, we could bind actions to events in the following way:
(define-event rocket-launch
(and (item-taken key-card)
(item-activated control-panel))
(then (play-sound rumble)
(pause 3)
(activate-object rocket)
(destroy-object hanger)))
All that remains is to create a compiler for this language that will translate these expressions into a lower-level form suitable for use in the game engine. E.g. the compiler could output C code suitable for inclusion in a DLL.