Given the requirements I was rooting for Guile. He ended up choosing TinyScheme. Those who have not kept up with Guile development for the last 4 years would, I think, would be very pleasantly surprised, I was.
It has been vigorously developed upon, lots of changes to make it more performant and you can catch the highlights of all this action on Andy Wingo's blog http://wingolog.org/tags/guile
Another neat scheme for games that I am aware of is ypsilon http://code.google.com/p/ypsilon/ one driving motivation for it was to keep GC pauses small, pretty important for games. I believe it has an incremental GC, not a fully concurrent one.
> The requirements included "Windows (compiled with MSCV) and iOS." Guile can do that?
Yep! with MinGW on Windows. IIRC they distribute such a prepackaged bundle. Will probably work with cygwin dlls too. Dont know about GUI inter-op, but Guile would build with Xcode
@xpolitix Good point about the need to link statically on iOS, had not thought about that one.
Guile looked to me firmly in the "midweight" category I mention in the article. I don't doubt it's a very good interpreter, in the same vein of Gambit or Chicken, but it required a combined size/platform commitment way above I was considering. Basically anything more complex than S7 is playing in a different league than little single-file interpreters like TinyScheme or femtolisp. If I had to start from scratch I would certainly consider a bigger, much more capable platform, but it's really late in the development of the game to add it.
I didn't know about ypsilon! The incremental/short pause GC looks very interesting indeed (although for the current usage in The Spatials I run TinyScheme as part of the map generation and then I completely unload it, so no GC, all the script logic gets encoded into command-like objets inside the C++ heap). But it appears it hasn't been developed for awhile. Still it's quite small, I will definitely look into in the future.
This is usually code for "needs UNIX/POSIX APIs", or its uglier cousin, "uses C99". I wouldn't mind Mingw32, and would mind a little bit Cygwin, but the problem is that for a video game I can't even begin to consider those platforms for Windows. All the official platform SDKs, or the third party ones (think Steam) require the Microsoft compilers and libs.
It builds under Mingw32 as well, and at least an earlier version built with VC++ without modification (I don't have access to a windows machine right now to verify). It also builds under Plan 9, which uses a very old and basic C compiler very far from C99.
Some of the optional extension libraries like networking may not work out of the box, but TinyScheme doesn't have these anyway.
Basically, Chibi was designed as a better TinyScheme. It's just as small, can also easily be included statically without a library, has a nicer (optional) FFI, various features like full Unicode, full numeric tower and hygienic macros (all optional), and is an order of magnitude faster.
There's also some weird double personality issues going on with their compilers in MSVC2013, for example they support designated initializers in plain C but not in C++. So you get partial C99 inside pure C or C89 (MS flavored) under C++.
I forgot where I read the quote, but for a decade Microsoft saw the plain C compiler as tool exclusively meant for Windows development. While gcc and later clang adopted and embraced new C idioms, like the struct syntax I mention, they kept their plain C support frozen in time.
I also found weird behavior in MSVC when pushing the C preprocessor VERY hard (nested variadic macros. That would require an entire blog post for itself...)
Guile LGPL makes it incompatible with commercial games on iOS (because exes are required to be statically linked). However, I think it's one of the best choices on other "more permissive" platforms.
The LGPL doesn't prohibit static linking. You are free to use static linking with the LGPL as long as you make the (potentially modified) LGPL source code and any other components of the linking process available. See section 4 d) 0) of the LGPL:
In particular, iOS WebKit has been distributed in this fashion. You can download a source tarball from Apple that includes static binaries alongside the LGPL portions of the source.
The reasons for not wanting the LGPL probably have more to do with the LGPL placing obligations on Apple to convey source code to users upon request.
| ... Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work ...
This is practically impossible to do with under Apple Store forcing digital signing of applications (forbidding combined work), even if the developer provides modified source code.
Embedded programming languages are really cool. Lua's still ruling the roost, as far as I've seen, but there are some nice options out there.
I'm currently using mruby for a project and have been quite happy with it so far. The community around it is still somewhat thin, but the code quality is good and development is quite active. https://github.com/mruby/mruby
I read that Io is frequently used as an embedded language. It's really nice, OO and prototype-based little language, definitely worth a look.
Out of interesting Lisp dialects, there's also PicoLisp (http://picolisp.com/wiki/?home) which looks like it should be well suited for embedding, but I didn't find any docs for how to do this with a quick search.
Indeed. TinyScheme being a single file of C code hides this fact at a first glance. I didn't want to diminish Lua, which I find quite good too (I wish LuaJIT was usable on iOS), but I was really looking forward to dive into Lisp.
LuaJIT is usable as an interpreter on iOS, just not a jit compiler. It is a very fast interpreter, but obviously this is not ideal (and the ffi is slower without jit).
Android L is also going to kill jit compilers as well alas, see [1]
Yeah I liked LuaJIT for the amazing JIT performance and the super fast FFI it enables. Exactly the two things that wouldn't work in iOS. I had no idea Android L was killing JITs. It's a terrible precedent seeing how many dynamic languages depend on a JIT to perform decently.
It's a chillout song, and, well, it's the home page of a videogame, so we thought we could get a pass with the video on autoplay. But it's been two people in the last 12 hours already complaining about it so I will disable it for awhile and see how it goes with conversions/ engagement. We well keep this in mind for future videos. Thanks for the feedback!
s9fes is another small Scheme that runs on Unixes, OS X, Plan9 & Windows. The code is in public domain and fully described in a very nice book "Scheme 9 From Empty Space: a guide to implementing Scheme in C". It weighs in at roughly 25% more lines than tinyscheme for *.{h,c,scm}.
My kneejerk reaction was "oh my god don't dump a general-purpose language into the runtime just to write mission scripts," but this is actually a good example of how to do it: The DSL defines some data structures that the C++ code uses, and has a direct handoff of the emitted results from Lisp into C++. Lisp doesn't have to interact with every frame of the game.
If you start exposing the engine in arbitrary fashion, things go south rather quickly; the scripting language will never stop finding more things it happens to need to get access to, and then you have an inner platform with boilerplate abstractions that make for worse tooling than whatever you started with.
It has been vigorously developed upon, lots of changes to make it more performant and you can catch the highlights of all this action on Andy Wingo's blog http://wingolog.org/tags/guile
I like his rundown of different Scheme implementations http://wingolog.org/archives/2013/01/07/an-opinionated-guide... including the comments that readers left there.
Another neat scheme for games that I am aware of is ypsilon http://code.google.com/p/ypsilon/ one driving motivation for it was to keep GC pauses small, pretty important for games. I believe it has an incremental GC, not a fully concurrent one.
> The requirements included "Windows (compiled with MSCV) and iOS." Guile can do that?
Yep! with MinGW on Windows. IIRC they distribute such a prepackaged bundle. Will probably work with cygwin dlls too. Dont know about GUI inter-op, but Guile would build with Xcode
@xpolitix Good point about the need to link statically on iOS, had not thought about that one.