xguile and guile-xlib

[Neil Jerram <neil at ossau dot uklinux dot net>]

[Copied to the list because there are general issues about interfaces
and compatibility here that others may have input on.]

Hello again!

I have had a pretty good look now at the xguile source that you sent
me.  I was quite impressed to see what an extensive collection of
Scheme scripts and examples xguile has, on top of the basic C stuff -
some very nice stuff in there, even including http client code!  (As
an aside to the list in general, I really think that it would be good
to set up some kind of Guile repository soonish...)

However, looking at this in detail has made me uncertain about whether
it is a good idea to try to merge xguile and guile-xlib, or to modify
xguile's interface and semantics to be more similar to what I have
begun implementing.  There are a number of points here:

1. xguile and guile-xlib differ in their approach to being an
   interface: xguile aims to be as thin as possible, while guile-xlib
   aims to add a few features that I believe make the interface more
   usable.  I know that you appreciate guile-xlib's additional
   features, but there is merit in both approaches, so it isn't
   necessarily right to coerce xguile, insofar as this is already
   a working and useful library, to take the guile-xlib approach.

2. There is some merit in having a library for both SCM and Guile that
   provides identical interface and semantics in both environments.
   Especially when so much Scheme code for it already exists.
   Therefore your work on xguile might be brought to a better
   conclusion by polishing the Guile compatibility parts of xguile and
   persuading the x(m)scm maintainer to include these in their
   distribution.

3. It's difficult to say this without sounding ungrateful and
   arrogant, but please understand that that is not my intention...
   The guile-xlib code is not at all *hard* to write, except perhaps
   for the bits that differ in approach from xguile; therefore I don't
   really *need* to lighten the task by borrowing code from
   x(m)scm/xguile.  Further, the licensing position of x(m)scm looks
   quite complicated (even ignoring the position for your
   contributions, which I understand that you are trying to address).
   For me, therefore, there's no strong imperative for merging with
   xguile, and quite a good reason not to.

Sorry for sounding so negative!  Looking at the situation more
positively, I'd say that there is an opportunity for both of

- in the short term, a thin, partial Xlib/Xt/Xm/Xaw library for Guile
  that is fully compatible in interface and semantics with the same
  library for SCM

- in the medium term, a second, complete Xlib library for Guile with a
  thicker interface that some people will prefer.

What do you think?  Best regards,

     Neil