I don't think the space of GUI development has yet been explored adequately, particularly where declarative and dynamic approaches are concerned. I also don't think Windows-based Common Lisp developers have enough options for GUI programming. Finally, I think more open-source code is better than less, arguments about balkanization and limited resources notwithstanding.

The argument could be made (and I believe has been, although right now I can't find the link to Havoc Pennington's blog entry where I think I remember him doing so) that the industry doesn't need another GUI API; who am I to think people will adopt my API, and why should they be bothered to try?

First of all, there always will be people willing try new things -- and they are great people from whom to get feedback. Secondly, there is no physical law of the universe saying innovation in the GUI API space is at an end, especially if you consider how many dynamically-typed, code-is-data libraries there are compared to the statically-typed, Algol-based so-called popular choices. Third, every one of the existing incumbents started with 0 fans (or 1 if you count the original designer). Fourth, I wanted (and still want) to provide Windows developers more options -- less reason to give up on Common Lisp. I'll spare you reasons 5, 6, and 7 since I think (and hope) you've gotten the gist. If not, oh well I tried.

I got interested in Common Lisp initially after reading Paul Graham's essays on Lisp, then grew more serious after buying a copy of Practical Common Lisp by Peter Seibel. I have grown to appreciate Common Lisp as a superior programming language for the kind of development I want to do in the long-term.

Compared to current popular languages and their associated frameworks, it's tempting to think of Common Lisp as being obscure. In reality, it has a long history, and there are well-known success stories. One of the attributes of Lisp making GUI programming a real joy is the ability to easily define powerful domain-specific languages, such as the DEFMENU language in Graphic-Forms. I don't regret shifting my focus to Common Lisp at all.

You can find more information about Common Lisp on the web here, here, and here. Or just read this essay and think about it for a while. In any case, if you're comfortable and productive using the tools you already have available, more power to you.

This is a hard question to answer in a satisfactory manner, because the premise is absolutely valid: developers prefer to support multiple platforms or at least have the freedom to change their focus. There is quite a bit of well-deserved ambivalence, if not hostility, towards Windows and the company that produces it.

Having worked for the company once known as XVT Software, Inc. in the early 1990's, I gained an appreciation for both the value of and the incredible demands imposed by software portability. There are existing Lisp-based GUI portability libraries, which I respect for their good intentions, not to mention the huge effort they require. Relatively few Lisp-based GUI libraries target Windows specifically, hence this is a niche I wanted to try to fill.

The bottom line is this: I want more people to write GUI applications for Windows in Common Lisp, and I hope you use Graphic-Forms to do it. As for the ABM crowd, if you don't like Windows, then you're welcome to ignore this project. Don't bother flaming me about it, as I will ignore you.

Graphic-Forms is in alpha and will be for the forseeable future -- a user interface library of this kind entails a large feature set. The code and documentation is under constant development, with new features being added at a rapid pace. Public interfaces have not yet stabilized, thus I cannot yet commit to backwards compatibility. This is a project with which (I hope) early adopters can experiment.

I will nevertheless point out how this project has gotten past the initial hurdle where other projects often die out. There are key aspects of the design (if not the implementation) of Graphic-Forms that I'm getting pretty happy with, and most of all, I've proven to my satisfaction the feasibility of building a user interface library in Common Lisp for Windows. I think a solid foundation is forming.

I expect to transition to beta when the majority of features are in place and what remains is essentially testing -- but it's a grey area and none of us can predict the future with any certainty.

I'm generally not inclined to do so. Writing an accurate and thorough comparison is a lot of work, whereas I'd rather spend the time and energy directly on Graphic-Forms. Also, there is a risk of my making inaccurate statements which might result in nasty email filling my in-box that I could live without, and perhaps even legal troubles.

Also, as far as my personal attitude regarding criticism of other people's work is concerned, I prefer to do so in the proper venue with more likelihood of such feedback resulting in improvements. See The Golden Rule.

Constructive criticism, bug reports, and patches are always appreciated and thoughtfully considered. Here are the main channels for participation:

• Developer mailing list
• Bug tracking system
• Patch uploads

Bug reports should be accompanied by self-contained test cases whenever possible. A quick note about your environment (Windows version, CL implementation, etc) is also very important.

Graphic-Forms is BSD licensed. As project founder/lead developer, I reserve the right to reject or modify patches as I see fit. But rest assured I am grateful to receive patches and will make every effort to understand and preserve the intent of any contributions. Finally, for any patch consisting of more than 2-3 lines of code, I will include your copyright statement in the relevant source file(s) along with my own.

I'm glad you think so! It's difficult to identify project names that are meaningful and relevant, yet are free of trademark concerns. The name Graphic-Forms is meant to be a play on words, since the library focuses on graphical features and forms is a term referring to fragments of Lisp code.