Looks nice. I only looked at the documentation though.

Possible bug: the documentation has:

> (x) -> int

Returns the current x position of the mouse on the graphics context.

> (y) -> int

Returns the current y position of the mouse on the graphics context.

but the example has:

        (let ((x (mouse-x))
        (y (mouse-y)))

For various reasons, I think it's best for language bindings to stick closely to the C API. For people who know the C API, digging around for the same function with a different name is frustrating. Also, the manual for the C API can serve, to some extent, for other languages also. I'm glad your bindings have not deviated too far but there are some (IMHO) unnecessary discrepancies.

Peter, the discrepancy is in the prefix. Im not sure if thats an mzscheme thing only but when you import modules you can prefix all the exported definitions with an arbitrary set of characters.

At the top of the example thing is this:

(require (prefix mouse- (planet "mouse.ss" ("kazzmir" "allegro.plt" 1 0))))

Which means anything that comes out of the mouse module will have mouse- prefixed onto it. I could have just left it alone in which case the code would be

(let ((x (x))
      (y (y)))

But then its not very obvious what (x) and (y) are binded to.

I suppose you may ask why not just export the definition of x and y from mouse.ss as mouse-x and mouse-y and the reason is because the prefix feature exists I didnt want to prevent people from doing as they wished with the function names. The only real naming requirements for the function is that they return what they represent, x returns the x coordinate and y returns the y coordinate. Any other naming convention is purely upto the programmer. If only C++ had this!!

Also, I noticed quite a number of typos and bugs in the documentation already. I was tired and wrote the whole thing fairly quickly, but I will update it as time goes on. Im going to basically rewrite the entire allegro.txt for this!