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