Hi,
List membership is exploding! Not counting myself twice, there are now three members.
For a while I've been unhappy with how event.lisp maps calls to the callback function to actual objects for event handling. I thought closures would be a nice solution to the problem but wouldn't have thought it possible. I mean, what does C know about closures? Well, it looks like OpenMCL may be clever enough to do it:
$ openmcl Welcome to OpenMCL Version (Beta: Darwin) 0.14.3-050429! ? (defun make-ff (ret) (let (fn) (declare (special fn)) (defcallback fn (:int) ret) fn)) MAKE-FF ? (defvar ff-foo (make-ff 10)) FF-FOO ? (defvar ff-bar (make-ff 20)) FF-BAR ? (%ff-call ff-foo :signed-fullword) 10 ? (%ff-call ff-bar :signed-fullword) 20 ? (quit)
This will mean some major surgery to the event handling code, but I think it will be much cleaner afterwards once I've got it all sorted out. There are other callback types used in the Carbon APIs that can also be handled by a more generalized mechanism.
I've also just added an Example module to CVS. It's there to show how CL-Carbon can be used to make a self contained application bundle work. I removed all slime references in that code to keep things very simple.
I'm not sure right now how to unwed from OpenMCL. I'm hoping that can be achieved with the appropriate macrology and CLOS classes. At the moment, I'm placing a higher priority on getting a class structure worked out that favors CLOS's features.
On May 2, 2005, at 7:28 PM, David Steuber wrote:
Hi,
List membership is exploding! Not counting myself twice, there are now three members.
For a while I've been unhappy with how event.lisp maps calls to the callback function to actual objects for event handling. I thought closures would be a nice solution to the problem but wouldn't have thought it possible. I mean, what does C know about closures? Well, it looks like OpenMCL may be clever enough to do it:
This does look nice!
I'm not sure right now how to unwed from OpenMCL. I'm hoping that can be achieved with the appropriate macrology and CLOS classes. At the moment, I'm placing a higher priority on getting a class structure worked out that favors CLOS's features.
That's exactly how I was starting to sketch out the abstraction... so far the main conceptual difficulty is the fight between macro vs. OO-style, and I haven't come down on one side or the other yet.
--chris
cl-carbon-devel@common-lisp.net