This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: should GOOPS be built-in?



I don't mean this as criticism of the developers since they are
spending their free time to work on a very good library.  I think it's
great that Jost is getting the new module system working, Greg is
documenting like a mad man, Mikael has got GOOPS into a usable state,
plus all of the other work that is going on.  

Mikael Djurfeldt writes:

    > My impression is that the Guile community in general is
    > rather weak when it comes to actually writing code. 

I don't think that's a fair criticism.  I'm afraid that there may be a
lot of guile code being written, but it's not making it into the core.
It's also pretty hard to maintain a separate package that other's can
pick up and use.  My personal experience has been that it's a waste of
time to clean code up and submit it.

For instance, there are the gh_lease routines that Val Kamyshenko and
I have put together based on long discussions from the guile-numerical
list.  The final version of this code has been on my web site since
Sept and the FSF paperwork is already complete, but as far as I know
none of the core developers have taken a look.  I suspect it's fallen
through the "maintainer change" crack and needs to be reannounced.

Patchs to improve guile never seem to get incorporated.  I recently
submitted patchs to make the creation of floating point uniform
vectors a little more sane (ie specify the type with a character
rather than depending on the internal representation of a number).
Clearly, it would be better to implement SRFI-4, but I'm not going to
waste my time doing that when I don't need it and minor improvements
aren't being incorporated into guile.

I've also got a separate package (guile-foreign) which interfaces to
CLisps vacall foreign function library. as well as providing an
interface directly to C-based pointers.  It also lets scheme routines
be used as callbacks within C (for instance Xt callbacks).  Guile has
been a moving target so it's sufferred from bit-rot.  The unfortunate
truth is that I don't have time to keep updating it.  Unless guile's
API stablizes separately distributed packages are not going to be very
useful.  

I use guile to get work done and I really appreciate the work the
developers are doing.  I'm quite happy to share code that I've written
for my own use, but there is little incentive to spend time polishing
it for submission when there's a good chance it won't be used.  I
suspect that I'm not the only person who feels this way.

- Clark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]