I'm a newbie here and don't know what Lisp/CLOS compiler to choose.
Is there a fast, free, cross-platform (Linux/Solaris/Windows)
implementation
with cross-platform GUI library? By the word "free" I mean GPL/BSD/LGPL
or a
similar licensed software.

Thanks in advance.

CLISP can be found at http://clisp.cons.org and it runs on Unix boxen
and Windoze (and DOS, OS/2, and Amiga 500-4000).

As far as GUIs go, the situation is pretty grim.  CLX will get you X
server graphics, but it's pretty low level.  There are several toolkits
built on top of it, check http://www.lisp.org/table/tools.htm#windows .
CLISP has bindings for gtk+, which is cross platform, but I'm not sure
if the bindings are crossplatform or how robust the bindings are.

Thom

I couldn't find any GUI toolkits that would allow me to build such a
thing with low overhead, so I ended up using with-wish.  Since a) this
was going to be used by non-technical people, who shouldn't have to
know TCL/Tk (ew), b) the layout needed to be created completely at
runtime, and would have different elements each time, and c) the Tk
widget set has some horrible inconsistencies which made a quick hack
difficult, I ended up basically writing my own widget set on top of Tk
and with-wish.

It's the first thing I've done in Lisp, so I don't know how good it
is, but in my biased opinion, I think it's rather nice.  It is
somewhat specialized to my particular app at this point, but I think I
should be able to break the GUI stuff out fairly easily.  It's all
based on CLOS, so creating a widget is as simple as doing
(make-instance 'type-of-widget) and then passing a list of these to
the creator function.

I'll post a URL in a few days and you can all discover my newbie
status in greater detail.

re:

  http://www.xanalys.com/software_tools/

It runs nicely under Windows and Linux (for Linux, install either
LessTif or Motif) and has a nice GUI API called CAPI that is easy
to use. I have the example programs from my (rather old) Springer-
Verlag Common LISP book on my web site, converted to use CAPI, if
you are interested.

I liked LispWorks enough to buy the commercial version,
which also supports the standard CLIM GUI API, and makes compact stand
alone executables(nice!).

-Mark

--
Mark Watson    www.markwatson.com

TIA

The commercial CLIM source is probably high in the list of software
pieces that are market-damaged by doing nothing but the initial
coding.

Is that to say that you don't agree with what has been said about CAPI (not
powerful , not well documented)?

I believe Martin ia right on all accounts. CLIM was never really
supported by the vendors.  The complexity of the beast is definitively
a drawback, and Common Graphics and CAPI would both offer the lock-in
of customers contrary to the standard CLIM.

As per CAPI, I toyed around with it some time ago and I found more
rigid than lacking. (The famous problem: how do I set the font of a
button *without* inserting it in a layout).  Documentation was
somewhat ok, but it could improve.

Cheers

 I looked at CLIM too, but either I did something

 I am thinking of buying the product, but my Franz rep tells me I need
to sign a letter of intent to purchase the product before getting a 30
day trial of it!!  In this case, I will wait to ACL 6 and see if their
Java link will provide an adequate GUI.

Assuming a seemless Lisp<->Java product, would anybody wish to speculate
the advantages that CLIM would provide over building GUIs using Lisp
with a Java GUI?

Thanks,
Dave Linenberg

I make it short, the experiences together with the narrowed feature
set and bad portability of CLIO/CLUE caused me never to use Lisp for
GUI programs.  I wish I had been stubborn enough to just use Garnet,
but at the time I wanted a CLOS-based solution for some reason.

Martin

  http://quadium.net/code/splash/

I know that a couple sections of code need a rewrite; there's a bit of
redundancy in the PACK code, etc.  Anyway, I would appreciate a
critique both of the program itself and of the widget implementation.
It's my first Lisp program, though, so please don't be _too_ harsh...
=)

There's certainly power there, and I believe flexibility, but the
documentation is completely lacking. I always wondered how the LW CAPI
differed from the system they designed for Dylan, which seems to have been
routinely praised. I get this feeling that there's a lot of potential in the
CAPI, but the reality is that it's seems to be lacking in many areas.

  This is scary stuff to the legally naïve, but a letter of intent is
  not a contract.  You are under no obligation actually to purchase
  anything if you don't want to after the trial period is over, but
  you have to notify the other party of a change of intent.  This is a
  means of maintaining control over who receives trial versions and
  ensures that they either return or purchase it within a reasonable
  time.

  There are lots of unnecessary legal papers to sign or deal with in
  most transactions, but they become necessary in a dispute.  If you
  haven't arranged for them beforehand, you're basically hosed.  In an
  over-litigious society like the American, this probably makes a lot
  more people than necessary feel like they are suspected of cheating,
  or at least thought capable of cheating, which by itself causes some
  to cheat in anger or spite, which sort of proves the point that the
  paperwork is necessary to protect oneself from such people...

Cheers

  http://ww.telent.net/cliki/SPLASH

to the CLiki site recently started by Daniel Barlow:

  http://ww.telent.net/cliki/

Since SPLASH is your baby (and since everybody has write access to CLiki :)
feel free to correct what I have written. Likewise, I encourage other
authors of free Lisp software to contribute information about their
projects to this new community resource.

Concerning your request for compatibility patches for increasing the
portability of SPLASH, you may check the subprocess management routines of
cllib, which is part of CLOCC (Common Lisp Open Code Collection):

  http://clocc.sourceforge.net/

I've spent the last decade wasting my time involved in Windows development using
MFC.

CAPI, with all of its faults, is wildly more productive.

The flexibility of CAPI seems to be underdocumented - it looked too limited when I
first read the documentation.  As I dig into it (with some frustrations) I find
that it can do everything I've asked for so far.

I spent a bit of time trying to decide whether to use Tcl/TK or CAPI or try to
attach TK to Xanalys lisp.  As an experiment, I transliterated a lump of Tcl/TK
into CAPI and found that the models weren't that far apart.  I ended up just using
CAPI.

CAPI's main problem is OOP-disease: documentation is sparse and abstract, you can
never nail an answer down without experimention.  This, unfortunately, is par for
the course - I've had this same frustration with Smalltalk and have had it in
spades with Java (and those bloody JavaDocs).

As far as portability goes, it is sad but true, that when I think of a product
that I want to sell/give to someone else, the only "portable" way to do it is to
develop it for Windows.  From this point of view, portability matters only if you
choose to develop on a non-Windows machine, then port the result over to Windows
before selling it.  [I wish it weren't true].  CAPI is well-suited for that.

Setting yourself on a single-vendor API with only one implementation,
with no source you may redistribute in an emergency case, is suicide,
time-invenstment wise.  I've been programming for long enough to know
this and who the specific vendor in question is couldn't matter less.

I have no doubt it's more productive than MFC, though...

  This has a very simple and obvious answer: You do what you always do
  when "the world" dissolves underneath a programmer: You reimplement
  your software with the best available tools and people at that time.

  It's a strange illusion that just because it's in some "free" form,
  it's going to stay useful forever.  Operating systems come and go,
  languages change and their compilers and development tools with them
  -- including such fickle things as the support libraries that change
  in subtly incompatible ways all the time.  And let's not forget the
  people who can actually make use of the specific combination of all
  of these things -- people have two nasty habits: (1) they forget,
  and (2) they die.  All of this happens all of the time -- regardless
  of whether you have source code to something.  Even the hardware on
  which the last system in the world ran will deteriorate and die.

  What does using stuff that follows standard buy you?  _More_ time,
  not eternity, and not even necessarily _much_ time, either.  If the
  standard is _excellent_ and it's universally adopted by someone who
  is not so cavalier about standards as Microsoft, it may buy you a
  lot of time, like 15 years.  If it's a bad standard, it will also be
  improved.

  Reimplementing is part of the maintenance costs of a project.
  You're a damn fool if you don't calculate it into the price of
  something that is going to be in use for a long time.  It's very
  much like longevity in data storage: If you don't plan to have
  someone copy data off of old media onto new media to keep it alive,
  possibly converting it in the process, it _will_ wither and die.

| Setting yourself on a single-vendor API with only one implementation,
| with no source you may redistribute in an emergency case, is suicide,
| time-invenstment wise.  I've been programming for long enough to know
| this and who the specific vendor in question is couldn't matter less.

  Then you should also admit that there is _no_ cure.  Just about
  everything is suicide, time-investment-wise: Everything dies in the
  end and under more miserable conditions the longer it has been kept
  alive artificially, I might add.  The question is how much time you
  lose or fail to lose (but that is not "gain") with each move you
  make.  There is nothing to indicate that having source code access
  buys you any more time than not having source code access does, in
  the general case.  Specific cases may of course be cited the same
  way alternative medicine cites its successes.