"Marco Maggi" <[EMAIL PROTECTED]> 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
_______________________________________________
Guile-user mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/guile-user
