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

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> He, that was sort of a teaser.  ;-)
>
> When I started using Guile, I was fully in sync with the "embeddable
> library" approach, which means that I'd write, say, 75% of an
> application in C, and then arrange to have the remainder written in
> Scheme in an extensible fashion.
>
> But I started really enjoying Scheme and wanting to write less C, more
> Scheme.  So why bother writing C at all when I could avoid it?  Well,
> for "performance reasons".

Completely agreed so far, except that there is another reason for
writing C code: simply to interface with a C library that already
exists.  There are a few of those out there. :-)

I have two lines of thought that are compatible with your account, if
not exactly the same.

1. The fundamental premise of writing in a scripting language must be
   that it is easier / quicker / more fun / more effective than
   writing in C.  Therefore one must want to maximize the amount of
   scripting language code that one writes, compared to the C code.

2. I originally thought that a software-component-using-Guile should
   typically be a complete application - such as Gnucash.  Now I think
   that a software-component-using-Guile should ideally be a library -
   such as a module providing operations on financial objects - and
   that applications should be created, in Scheme, through relatively
   trivial composition of sophisticated libraries.

> And what are those "performance reasons"?
> The interpreter is pretty slow, which is definitely not due to inherent
> limitations of the language, but to the implementation.

I haven't personally been gated by this yet, but I can't disagree with
it.

> I'm convinced that it's possible to write a Scheme interpreter much
> faster than ours.

It must be possible, because other implementations have done it.

It's difficult at this point to avoid a possibly unwelcome question:
what makes Guile Guile, and why wouldn't we be better off contributing
our resources to an implementation that already is faster?

(I believe that we _do_ have a collection of features that makes Guile
currently unique, but I can't rule out the possibility that another
implementation might be open to accepting enhancements that would
incorporate these features.  But perhaps someone else has done the
analysis, and so _can_ rule this out.)

>  So I think that's one route we should take in 1.9.
> The next step would be to have a compiler (to byte code, to C,
> whatever).  However, I think the interpreter should keep playing a
> central role in Guile (because it always did, and because it's often
> convenient to work with an interpreter), which is why I would consider
> improving/rewriting the interpreter a major goal for 1.9.

Those are welcome goals, and I'm sure that I would appreciate the
increased performance.  

> Maybe we should start a discussion about what we'd like to see in 1.9?
> :-)

The kinds of things that I am most interested in are:

- finishing off the debugging infrastructure

- progressive completion and polishing of the manuals

- improving tracking, provision and regression testing of the
  available Guile add-on libraries; also providing interesting
  examples of how interesting things can be achieved by combining such
  libraries

- possibly integrating with other systems' library repositories (such
  as Snow)

- in general, any kind of situation where we can create value just by
  putting existing stuff together (another possible example: the Emacs
  Lisp translation support + existing Emacs Lisp libraries), or by
  better tracking of what's available.

The phrase "what we'd like to see" is IMO unrealistic, though.  I
don't think any of us (Guile developers) can commit to achieving
particular things by particular dates, and I wouldn't wait to delay a
new release, once a sufficient amount of interesting new stuff has
accumulated, because a particular target has not been met.

Regards,
        Neil