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: I resign as Guile maintainer


forcer <forcer@mindless.com> writes:

> [i cut off most of the extra recipients - this mail is more
> important to the guile list than to anyone else]
> 
> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > [...]
> > it is a clear signal that something is wrong with
> > the Guile project and that something needs to happen.
> >
> [...] 
> >
> > Now, what's going to happen with Guile?  Is it dead?  Or merely ill?
> > Is its illness infectious?
> > 
> > I don't know.  I'm kind of emotionally attached to Guile, because it
> > is the project that was my ticket into the Free Software community.  I
> > still have the letter from the FSF pinned to my wall that I got when
> > signing over my copyrights.  So, it's hard for me to just let Guile
> > die.
> 
> Same for me - i'm just hoping for a chance to commit some bigger
> change so a copyright signover would be feasable :]
> 
> > I never really resonated with other Scheme implementations either.  I
> > slowly began to think that SCM was a good choice as the basis for rms'
> > goals of a universal extension language, although I didn't understand
> > it in the beginning.  Its design decisions fit well with being a
> > library in a C world, and yet it is efficient and makes no
> > functionality compromises.  So, I don't think Guile is fundamentally
> > technically flawed.
> > 
> > In my opinion what's wrong with Guile is that it develops more and
> > more into a patchwork of half working concepts.
> 
> That's the one big problem. And it's not a surprising one, given
> such comments as "we need a maintainer that's not afraid of eval"
> or "once i figured out the internals of guile".
> 
> Scheme is a very clean and simple language, and it shouldn't be
> such a big problem writing an interpreter for it that's halfway
> easy to understand if you sit down for a few hours and read the
> source. It's one of the paramount objectives in current software
> projects - the maintainability. And in my humble opinion, Guile
> in it's current incarnation fails exactly there.
> 
> The evaluator - as astonishing as it is, great work Aubrey - is
> *very* difficult to understand, even if you know C quite well and
> sit down for a week. The ifdef's etc. add even more difficulties
> there, though they are "justified" in eval.c.

But how often does anybody (not working on the evaluator) need to
really look at it? The evaluator is complex; though scheme is not a
really complex language, evaluating or compiling it efficiently is
going to be a bit involved. There are some things that do need
rewritting, but the question to ask is: will it be rewritten simply,
then, over time, accrue all the current baggage again? Will the new
baggage be better than the old, or will it slowly be pasted on to the
new `simple' code, until it makes the current evaluator look really
pretty? 

Just from personal experience, I used to flog the evaluator a lot
;). I was looking at it, getting as far as memoization, then saying
`bugger it, this is too loopy'. Lately, I've had no choice but to go
through the whole thing, and it really isn't that bad; there's a lot
too it, certainly, but once you see it through it makes an awful lot
more sense than just pondering a small bit of the code for it's
ugliness. It's also quite fast, and as much as we will say `a
scripting language doesn't need performance,' one of the most popular
(if not the most popular) scripting languages right now is perl, and
perl's major attribute is it's speed (there is more, of course, but
the fact that it wasn't insanely slower than doing it in c really
pushed it's wide spread adoption).

> The bit-tags are three-layered, if i understood correctly, and
> not too easy to understand either. The existence of macros to
> test for types helps a bit, but if you have to check for some
> bug, it's not *that* easy.

This is something that needs to be overhauled. There are a lot of
things that do. I can understand what you're getting at (I've felt
much the same way), but I think what we have to keep in mind is that:

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.

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.


-- 
Greg

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