[gameprogrammer] Re: Designing a language
- From: Charlie Lobo <charlie.lobo@xxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Fri, 23 Oct 2009 16:50:08 -0500
Javascript works in a similiar manner. As a matter of fact many people have
proposed that Javascript is LISP with C-like syntax. Closures are Lambdas,
objects, which are really dictionaries, are lists (only that instead of
using order to recognize objects, an identifier "name" is used now), etc. Of
course this isn't quite so, javascript is procedural, vs. functional, etc. I
can still see the value and it has oppened my eyes into how languages are
still becoming more like LISP.
On Fri, Oct 23, 2009 at 4:34 PM, Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:
> 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:
