Re: guile: going the way of DEATH

[Bruce Korb <korbb@datadesign.com>]

Didier Verna wrote:

>          * The docs are absolutely out of date. This makes guile unusable
> unless you're a guile developper yourself. You can't ask people to learn the
> code by heart in order to be able to use a package. This is a real showstopper
> for new people to get involved too.

Amen.  Long ago I volunteered to review gh_* documentation,but Jim got derailed
and the project sits.  I still would
like to convert my Autogen project to Guile (for political
reasons more than anything), but I also refuse to read code
to figure out how to do it.  If my project were a simple
matter of interpreting a source string, I think I could wade
through it.  But it is different, so the application of Guile
is non-obvious to me and, as stated above, having to read code
is a showstopper.

>         * Another showstopper is the apparent lack of will to help newcomers
> solving their problems. OK, it's August. But I don't see how you can expect to
> get more people involved in the developpement if you don't help them getting
> started.

Yep.  If anyone were able to tell me how I could applyGuile to my stuff, then
I would have moved forward and
blasted out the grunt work....

>         * You can't either expect people to use the snapshots. People need
> stable releases. I'm not against the idea of moving the API, if it can improve
> it. But people must be informed of the incompatible changes from stable
> release to stable release.

I would settle for snapshots that were labeled "robust",tho more regular releases
would be better...

>         * As far as I could see, but again, this is a newbie view, the gh API
> seems strange, uncomplete and inconsistent.

I believe, ultimately, I will need to construct a pre-parsedtree containing the
function calls and arguments that then gets
processed by the Guile engine. Many (most?) of the functions
need callback support.  Not clear how to do all that.