On Tue, 2007-12-04 at 07:50 +0100, Marco Maggi wrote:
> 3. For Guile 2.0 backwards  compatibility at the C level can
>    be broken. Freely. No shame. No blame.

This message references another message that I can't find:

http://lists.gnu.org/archive/html/guile-devel/2003-04/msg00076.html

> 4. If  a garbage  collector allows  to remove  the  need for
>    "scm_remember_upto_here"  it must be  adopted even  if it
>    makes Guile slower  and it raises memory usage  a bit (or
>    more than a bit). 

I am not a GC expert, but it is my understanding that as long as SMOBs
can own non-GC-controlled mallocations freed by the SMOB free function,
you need those macros/functions, GCPRO structures, or refcounting to
work with C code that can poke at their contents.  I guess you could
disable GC while executing subrs not marked safe-for-GC....

> 6c. GMP  support should  go into a  loadable module  (do not
>     nuke my mailbox, please).

Er, what would happen if you overflow fixnums?

> 7a.  It makes no sense to discuss if Guile should go R6RS or
>     not.   The  only meaningful  discussion  is about  which
>     hooks are needed in  Guile's code to make those features
>     available   as   loadable   modules.   (Yes,   this   is
>     difficult).

7a1. Inter-module hygiene/implicit exports.

> 1. TCL  has nice  programs that  allow to  distribute single
>    file  auto-extracting-and-running  archives  holding  the
>    core executable,  shared libraries, pure  TCL modules and
>    some data files (search for "tclkit").

I know of SBCL, CLISP, and PLT also doing this, but much more
sophisticated for the former 2.

-- 
Our last-ditch plan is to change the forums into a podcast, then send
RSS feeds into the blogosphere so our users can further debate the
legality of mashups amongst this month's 20 'sexiest' gadgets.
        --Richard "Lowtax" Kyanka