[gameprogrammer] Re: Designing a language
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Fri, 23 Oct 2009 16:34:11 -0500
On Wed, Oct 21, 2009 at 3:53 PM, gorm <gorm@xxxxxx> wrote:
> Hi People,
>
> Being a bit of a lurker on this forum, I thought all the chat about
> designing a language in the Daydreaming thread, would be a perfect
> opportunity to talk about a project of mine.
Welcome into the light! On this list lurkers out number posters about
5 to 1. Always interested in hearing from anyone on the list.
>
> I am big fan of functional languages. In my last game company, 3 Lives
> Left, we used OCaml quite a bit. A problem was that there isn't that
> many game development libraries out for OCaml out there, so we ended up
> writing our own FFI layer for OGRE, SDL, etc. There exists automatic FFI
> generators like SWIG, but it doesn't really pass advanced C++ code very
> well (like that in OGRE) and the interfaces it generates seem quite
> heavy.
>
> The problem with the approach above is that it does not work very well
> across platforms, especially when it comes to more embedded(like)
> platforms such as the iPhone, PSP Go, XBox 360, etc.
>
> Since then, having worked a bit with lisp, I have become a big fan of
> "interactive programming". Nothing beats developing or debugging a
> programming while it is actually running.
Yes! I am an old lisp coder and that is something I miss in "modern"
languages and IDEs.
>
> So the new idea is to build a small, and very tiny C++ game and
> interpreter engine around a lisp interpreter. I am using the
> boost::spirit libraries for parsing, and it seems to work quite well.
> The basic idea is to have as much engine and game logic written in my
> lisp variant.
That was my first idea for what became Stonewolf. It is a good
approach with lots of good history behind it. Ever hear of Autocad and
AutoLisp? AutoLisp is dervide from an early version of XLISP. IIRC the
first versions of XLISP were released with a very lenient license. The
guy who developed AutoCad tooks XLISP and added a nice input system
and a graphics system and wrote AutoCad.
BTW, I've written a few Lisp interpreters and a Lisp compiler. Spirit
should be very good for building Lisp parsers. All the Lisp parsers
I've ever seen (several written by people other than myself) were
recursive decent parsers. I once, on a bet, wrote a Lisp interpreter
in Microsoft 8K Basic on a Z80 with 32K of RAM. I won the cup of
coffee...
>
> Now, my fundamental problem is how to design a good interop (or ffi)
> layer? Ie. how do I design an easily extensible system, where I don't
> have to do a lot of C++ implementation everytime I want to introduce a
> new C++ type that can be reached from lisp? Ie how do I in a good way
> make it possible to create windows, build a physics system, instantiate
> a renderer, detect mouse input, etc in a coherent and clean manner from
> the lisp code?
Yep, that's the problem. Lisp does a pretty good job with handling
objects by treating them as a-lists or some other kind of associative
container. Wrap up the objects you want inside of Lisp associative
stores and then find code to the function value of the names.
>
> I have worked with one such system before, where each C++ type
> essentially agregated a scriptable type that acted as a bridge between
> the two domains. Though clever in some ways, the bridge type had to be
> extended with a new method whenever a new method was added to a
> scriptable C++ type, and so forth.
Yeah, that is the trouble with C++ no way to dynamically add methods
to classes at run time. I have to tell you, the first time I tried to
program in C++ that fact about C++ caught me completely by surprise
because I was used to doing object coding in Lisp. I thought that
"class {}" in C++ was something that was evaluated at run time, not a
compile time declaration. Drove me nuts.
The way to do it is to pass the *name* of the action/method to the
bridge class. The name can be part of an enumeration, it can be an
address, it can be a string, what ever works. Along with the name you
pass a list (or vector) of the parameters. The class looks up the
action associated with the name. That can be done by use of a switch
statement, by indexing into an array, or by looking it up in a
database. Then it calls the code associated with the name along with
the parameters. You still have to create the code for the action, but
you do not have to change the interface to the class.
Bob Pendleton
>
> Any good ideas, links, comments, etc?
>
> Cheers,
> Gorm
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>
--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email: Bob@xxxxxxxxxxxxx
+ web: www.TheGrumpyProgrammer.com
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
