Re: Plan for 2.0

[Neil Jerram]

2009/1/5 Ludovic Courtès <address@hidden>:
> Hello!
>
> "Neil Jerram" <address@hidden> writes:
>
>> 3. The "ossau-gds-dev" branch.  This contains some minor improvements
>> to the Emacs interface.  After the review of "master" is done, we'll
>> merge "ossau-gds-dev" into "master".
>
> I'd do (3) before (2) because it's probably easier.

Agreed.

>> Is there anything else?  In particular, am I right in thinking that
>> the BDW-GC work is not ready yet?
>
> The BDW-GC branch is fully functional, and the user-visible API changes
> are frozen.  What may (or may not) be a stopper are:
>
>  1. The lack of `gc-live-object-stats'.

I doubt it's a stopper, but current `gc-live-object-stats' is quite
nice.  Doesn't libgc have a lightweight object-collected hook that
would allow us to implement this?  Or is it the problem that would be
too bad for performance?

>  2. Different fields of `gc-stats'.

I would say that this is fine.

>  3. Different behavior of weak hash tables, see
>     http://lists.gnu.org/archive/html/guile-devel/2008-11/msg00015.html .
>     This can be fixed, but I'm unclear whether it's worth it (comments
>     welcome!).

IIUC, your example to the GC list can be fixed (in the application) by
using a (BGC) doubly weak hash table instead.  I wonder what is the
simplest example of a current Guile weak-key hash table that can't be
mapped to a BGC doubly weak one?

>> One specific query...  Although I advocated removing GH before, I
>> don't feel 100% confident that that's the right thing for 2.0.  I'm
>> wondering now if we should instead move the GH code into a separate
>> library, "libgh", but continue to provide this as part of the Guile
>> distribution.  Moving the code out of libguile will still achieve the
>> important objectives of (1) reducing the size of the libguile code
>> that developers need to look at and work with, and (2) ensuring that
>> GH is implementable on top of the advertised SCM API; but keeping
>> libgh in the distribution will be a significant help for users who are
>> still using GH (who will just need to add -lgh to their link line).
>
> I never considered it urgent, but I think it should be either completely
> removed (as is currently the case) or left in `libguile'.  Moving it to
> another library would make it essentially worthless since it would make
> it incompatible anyway.
>
> We could ship a C compatibility header as Andy suggested, but I'm not
> sure it's 100% needed.

Is your view on this a strong one?  I feel fairly sure that we ought
to continue to distribute this code - but in a deprecated and
undocumented separate library - because I think by doing so we can
help users with negligible ongoing maintenance cost.

Thanks!
      Neil