Log in

No account? Create an account

Previous Web | Next Web

I've started looking seriously at how I'm going to undertake this new project of mine... and it looks like the concept was really a bloody big monster in disguise... pretended to be a cute little cuddly project idea, when really it wants to eat my braincells for breakfast!


OK, so to date, tasks that need to be accomplished to get this off the ground are:

  • Get to grips with Lisp, because the guts of this thing are almost certainly going to use Game Description Language (GDL) (or atleast a derivative thereof) from the Stanford Logic Group's General Game Playing project...

    OK, so General Gaming Playing (GGP) is an AI thing...
    The idea behind GGP is that your Chess Playing AI is useless outside of that very specific problem scope... Deep Blue may have beaten a world Chess champion, but it couldn't remotely conceive of how to play draughts/chequers or tic-tac-toe..!
    So GG tries to create AIs that can be given a set of game rules (not the ones on the inside of the lid; the rules include things like all the legal squares on the board, etc) in some form and can play
    any game that can be described by that descriptive form. GDL is such a descriptive form (language).

    Now, I don't want the whole AI-side of this; I just want the ability to describe the initial state and control logic for a large-and-complex finite state system and to have a reasonably easy way for that description to be used to test the legality of state transitions... GDL is fundamentally a way to describe a large finite state machine without having to explicitly define everything about every state; instead, GDL describes a Game in turns of predicate logic, ie the players, the initial state and rules of what constitutes legal moves, etc.
    Because its predicate logic-based, its getting into Prolog territory, but this comes from an AI background, which may be one of the few places Lisp is still big.... the GDL spec is Lisp, and two of the reference players are written in Lisp... and I always wanted to learn Lisp... so Lisp it is!

    I did
    think about trying to write a GDL interpreter + FSM 'walker' in PHP, but then I came across the reference GDD players provided by SLG... the sample Lisp players are about 5k as tar.gz files... about 25k extracted, and should be executable as-is... the Java reference player is about 380k as a .tgz, admittedly comes with fluff (docs, Ant build files, etc), but extracted, there's 5Mb of it , with 325kb of .java files.... (and if memory serves (and they didn't improve things), .class files aren't really drastically smaller than their .java sources)... and while Java may not be fabulous for small source files (just think about Java's "print" statement......), I suspect its very complex to write the interpreter+walker in a language that doesn't have the nice functional-programming and inherent logic capabilities of Lisp (or Prolog for that matter)

  • Come up with a viable way to use Lisp from inside PHP. This almost certainly means one of the following options:

    • Wrapping a Lisp interpreter library up in a PHP extension... There is atleast one such library (part of Embeddable Common Lisp/ECL) that can be used for embedding in C. (Not sure about others... gonna look into GNU Common Lisp (GNU CLisp/GCL))

      Thoughts: Lots of C (which is not really a language I know too well...) involved in this option, and lots of calling and code conventions so that the C can talk Zend-engine.

      BUT, (1) there are a few tutorial-walk-through things around, (2) the C is (hopefully!) mostly boilerplate stuff and (3) there are tool(s?) supplied with the PHP sources that generate some of the files for you... so it may not be
      too bad.

    • Use a PECL Extension that never made it out of Alpha... FFI (that is, Foreign Function Interface) and write the wrapper stuff in PHP.

      Thoughts: Uses less (or even no) C, but FFI looks to have been abandoned for atleast 21 months (thats the most recent CVS commit stamp I've spotted (a bugfix) and the last official release, v0.3, is dated 20th Jan, 2004)... so I'm not sure its really safe to go down this route (ie, I would put money on this Extension not working in PHP6 whenever that arrives)...
      Oh yeah, there's also a statement that is "mostly works"... which makes me think that with my luck, the bits that don't work would cause me headaches!

    • Compile the Lisp program and wrap the compiled version up in an Extension or FFI.

      Thoughts: Various Common Lisp systems appear to have 'compile to native binary' compilers (the ones I've looked at are basically a Lisp-to-C converter that feeds its output to the system's C compiler, like GNU's f2c command ?does:used to do)

      This just doesn't seem like The Right Thing To DoTM!

      Afterall, I suspect that other people might find the notion of a Lisp interpreter that can be called from PHP rather more interesting/potentially useful than a very task-specific gizmo.... which (potentially) might mean that the LispInPHP implementation would get exposed to a bit more testing than the task-specific implementation.

      This is therefore a last resort only!

And that little lots is all before I can actually start work on the project proper!