Re: the future of Guile

[Neil Jerram]

"Marco Maggi" <address@hidden> writes:

> 3. For Guile 2.0 backwards  compatibility at the C level can
>    be broken. Freely. No shame. No blame.

Disagree, in general.  Why should we be arbitrarily awkward?  If there
are specific motivations, we should consider those case by case.

> 2. GOOPS always there. 

I think I agree.  I haven't developed Ludovic's suspicions yet.

> 3b. Death to  structs!  IMO they were "an  attempt", but the
>     resulting code is awful (sorry, but can you disagree?). 

Err.. but aren't structs the main part of how GOOPS is implemented?

> 6. More modularity. 

Yes, definitely, in general.  Like others I don't agree with trying to
split up the numerical tower though.

> 8. Hackability of the core. If nobody understands it...

Is it really that difficult?

(Actually the array code is pretty nasty, that could do with cleanup
if we can do that without breaking it!)

> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>
>       typedef SCM scm_t;
>
>     Emacs font locking kisses "scm_t" automatically.

Surely there's an elisp incantation that would make it kiss SCM for
you?

> 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 don't think that a programming language should have its own
packaging system.  Instead, we should provide tools to make it trivial
to package up Guile code into the common kinds of distribution
package.

> 3. Resurrect SCWM (Scheme Constraints Window Manager).

I've settled happily on ion2 now.  I suspect a WM may be one of those
things that doesn't really need much scripting, so I'm not sure what
SCWM would be aiming at.

Regards,
        Neil