Re: I resign as Guile maintainer

[Greg Harvey <Greg dot Harvey at thezone dot net>]

forcer <forcer@mindless.com> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > 1) There is, in any large project, a cost to becoming familiar with
> >    it. Rewritting everything wouldn't make this cost much smaller,
> >    except to the people doing the rewritting. The eventual results may
> >    even be more complex.
> 
> The problem i was hinting at isn't that it's difficult to get
> into Guile internals, but that it's unnecessarily difficult.
> As someone else (sorry, forgot the name) hinted, a very clean,
> very small core with a stable C API would be sufficient. It just
> has to be easily extensible. And the "smallness" should be chosen
> from a C programmers' view, since it's a C extension library (as
> much as i hate to say it - i prefer coding scheme to c alot).

That's really what the gh_* interface is supposed to provide. It
should be possible to sit down with a manual describing the
gh_interface and be able to get full use of guile, without ever having
to know that a long with the second bit set is an inum, or that the
evaluator is memoizing wildly, etc... If you were to think of guile as
a person, the internals is that person standing up naked; there's
nothing wrong with that, but you really want that person to put on
some clothes before they come to the dinner table.

As for core size, all that's really standing in the way of greatly
slimming down the core is some modifications to the dynamic linking
(isn't there a library from the libtool people that provides a nice,
platform independant way of dealing with shared libs, that takes care
of most of the hassles?) and a bit of modification to the
`unnecessary' files so that they can just be added by a (use-modules
(guile uniform-vectors)) or (srfi uniform-vectors) or whatever it'd be
called ;).

> 
> > 2) Even though it often doesn't seem that way, it is often much
> >    quicker to become familiar and build on or fix, than it is to start
> >    from scratch.
> 
> That's true, and i've checked through quite a few projects in the
> past, but Guile makes it unnecessarily difficult to "get" it. One
> part of the problem is surely that it's not too well abstracted,
> internally. E.g. the evaluator exposes some of it's internals to
> the exterior world. But oh well, i just wanted to express what i
> felt about the Guile project, i don't want to be the bringer of
> evil messages :)

Not really evil (eval? >;). I do think that some bits are horrid; I've
been knuckling down to finish up the gengc stuff before the end of the
month, so I've basically been going through all of the guile source;
eval wasn't bad (I was a bit surprised... the memoization is the only
real tricky part; I think that, as a whole, it really isn't as bad as
it seems on first glance, and I haven't spent hours pouring over it);
there are some bits that haven't stopped making me think `gack',
though. The lack of documentation really doesn't help, either (I
would've written a little doc about the eval, but I'm trying not to
get distracted from the gc stuff until there's something working).



-- 
Greg