Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

Adding my two cents to the "wish list"...

"Julian Graham" <joolean@gmail.com> 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
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel