Re: development goals (was: [PATCH] Avoid `SCM_VALIDATE_LIST ()')

[Neil Jerram]

2008/9/7 Han-Wen Nienhuys <address@hidden>:
>
> OK - I will admit that interpreter/GC hacking is cool, but on the
> downside, when I try to do anything, the intertia/resistance I feel in
> the community here is a big turnoff for me.

Do you mean regarding releases (as you say more on below)?  Or/also
the mailing list dynamic/responsiveness?  Anything else?

>> FWIW, I would like to run my code on other schemes -- not the same goal
>> as this one, but it overlaps considerably. For me, I think that the path
>> will be implementation of some scheme standard that supports modules,
>> then migrating code over to that standard. I'm not sure about R6 though.
>
> Is there a Rx/SRFI standard for modules? I always thought that module
> system(s) was one of the unspecified areas.

R6RS specifies libraries, which are similar to modules.  (But probably
much cleverer for separate compilation, and vastly more complicated in
their semantics.)

> I am probably the only person who is in both camps currently.

I've used Guile for a substantial project at work, and I use it for
various little things on my free software machines.  But it's true
that I don't have anything to compete for size/complexity with
Lilypond.

> When working with the devs here I continue to be puzzled by what the
> objectives are.  For instance, we had 5 major (stable) releases in 11
> years.  I have always wanted this rate to go up, and have tried argue
> for that, but with 1.10 (or 2.0, whatever it is called) being in
> preparation for 2.5 years at this moment, I don't see this changing.

For me, almost all of my time since becoming a maintainer has been
absorbed by working on bug fixes, largely to do with slightly odd
platforms (e.g. Mac) or architectures (e.g. ia64).  IMO it was
worthwhile to focus on such bug reports soon after they were reported,
because (i) the reporters are still around and interested enough to be
able to provide more info and test fixes, (ii) I believe that running
on more platforms will be good for the Guile community, and for Guile
applications.

Nevertheless, I have also had a rough plan in mind, which I've never
communicated before, except vaguely to Ludovic.  I believe Ludovic
disagrees with this plan, so it certainly isn't official.  It's just
what I'm thinking, and so might be part of what eventually happens.

Basically, my feeling is that Guile users have been badly burned by
major release incompatibilities in the past, and I really don't want
that to happen again.  Therefore my "straw man" plan is that

- we stay on 1.8.x for a while

- we treat "master" as a pot of goodies, which we aim incrementally to
merge across and release as part of the 1.8.x series

- in effect, therefore, we will be releasing one (or a small number
of) new feature(s) at a time - which I hope will give us the
time/space to consider and document any incompatible issues that there
may be

- we don't do a big jump to 1.10.x, by just deciding to do so at some
time (+ a bit of pretesting), because I don't feel confident that we
can properly consider and document all of the 1.8 .. 1.10
compatibility issues at once.

But #1 : as I said above, I'm pretty sure Ludovic disagrees with this!

But #2 : actually, right now I don't even know in detail what is in
master.  I plan to review that soon, and it may be that the detailed
results completely change this.

> At such a glacial pace of development, you would imagine that backward
> compatibility would not be a concern

Huh?  That makes no sense to me.

> - after all, who plans for
> compatibility over a five year span,

I believe that programmers' natural tendency is to plan for infinite
compatibility.

> yet Guile continues to support
> (by default!) the GH interface which was deprecated in 2002 (or was it
> with version 1.4 in 2000?).

There you're right.  We can and should rip GH out now.  Actually that
might make an excellent first example for documenting incompatibility.
 (Anyone who really still needs it can take on the burden of
maintaining the GH layer themselves.)

> For LilyPond (and any other package that uses Guile, eg. texmacs,
> snd), this is a problem, since we can not realistically ship anything
> that requires the latest Git/CVS version to work.  Hence, my
> improvements in LilyPond are held back by Guile's release scheme.  For
> example, I wanted to use SCM rationals for various purposes in Lily
> for a long time, but had to wait for the 1.8 release before I could do
> this.

Are there items in master now that you are particularly wanting /
waiting for?  I guess the GC is one, any others?

Regards,
        Neil