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

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> 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

I think I understand the point here, and it seems to me that this is
an improvement for the developer, not for the end user; and IMO not a
significant one (because it's pretty trivial to write a smob mark
function).  It also implies a performance cost, from scanning regions
of SMOB memory that Guile currently knows cannot contain heap
pointers.

> 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.

(I don't understand these ones in detail, so there may well be
significant benefits here.)

> 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.

Interesting.  Do you think that that would be a lot faster than the C
code we have now?

>   * 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}.

Great; I've been thinking that we need this too.

>   * Provide some Unicode support.  The hardest part, I think, is that
>     we'd probably need to rewrite/extend the C port API.

I'm pretty Unicode-ignorant, but I've read enough to think that this
area is important.  Is the problem with the C API just that it has
"char" everywhere?

Regards,
        Neil