Hi, Adding my two cents to the "wish list"...
"Julian Graham" <[EMAIL PROTECTED]> writes: > Well, for what it's worth, faster live "interpretation" of Scheme is > really important to me, whether that means some kind of Scheme JIT > compilation a la GNU Lightning or whatever. I believe the major interpreter performance improvements are to be gained by algorithmic optimizations (e.g., closure invocation, variable lookup), rather than micro-optimizations such as JIT. That said, JIT is a fascinating domain. :-) > * Faster GC (this is probably pretty similar to "faster interpretation") I'm (still) interested in comparing the space/time tradeoff in Guile and the `libgc'-based Guile. We'll see. Besides, I think using libgc would yield a number of practical improvements for the end user: `scm_set_smob_mark ()' would become useless in most cases and so would `scm_dynwind_free ()', `scm_set_smob_free ()' could be avoided almost entirely in guile-core, memory leaks would become less likely in the presence of non-local exists, marking a tree-like structure would just work (see http://thread.gmane.org/gmane.lisp.guile.bugs/3558), etc. > * Integrated debugging and profiling tools > > * Guile was initially proposed as a multi-language scripting platform; > is that still part of the mission? As Neil suggested, I'd say "no" for the time being. > * Not related to 1.9 itself, but maybe a cleanup / redesign of the web > page, including a cleanup of active projects, better integration with > Savannah for bug tracking, etc. Right. I've been meaning to update the projects page for a while actually... > * Thorough updating of the documentation > > * Integration with Free Software VMs -- Bigloo currently lets you > compile Scheme to CIL; it would be neat if you could do the same with > Guile and then run on top of DotGNU. Or Kaffe. Or anything else. I'm not too fond of CIL/Java bytecode, but choosing the bytecode format should not be the most difficult thing. ;-) OK, so my goals for 1.9 would be: * Evaluate `libgc'-based Guile (see above). * Rewrite the interpreter in Scheme (or a subset thereof), with a tiny Scheme-to-C compiler. That could be done in such a way that we could re-use, e.g., the memoization and unmemoization code that already exists in the first step. * Provide a documented C doc snarfing tool, written in Scheme, with a public Scheme doc snarfing API. I started looking at it based on the modules I wrote for doc-snarfing in Guile-{Reader,Avahi,GnuTLS}. * Provide some Unicode support. The hardest part, I think, is that we'd probably need to rewrite/extend the C port API. Comments? Thanks, Ludovic. _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
