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

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

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:

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

Of course.  But I mean: when you *could* avoid writing C, e.g., because
you don't rely on any specific C library's features, it often occurs
that you actually can't avoid writing C because of performance reasons.

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

Agreed (although I'm not fond of the term "scripting language", since it
conveys the idea that the language, not the implementation, is limited
to a particular use case).

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

Agreed.  Still, as you compose more and more such libraries through
Guile, you end up having more and more Scheme code, and (potentially)
more and more performance concerns.  :-)

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

Indeed, that's a good question, although a tough one for someone that's
too "emotionally involved" with Guile.  ;-)

To be honest, I don't know other implementations well enough to compare
available features.  I have the feeling that Guile's public (Scheme) API
is pretty good and quite rich.  We have POSIX multithreading, which not
all implementations support; we have a nice module system (although it
doesn't play well with macros ;-)), and of course a good and
well-documented C API.  Your new debugging infrastructure contributes to
Guile's friendliness.  Kevin's Guile-Lint is also an important
contribution to Guile's usability IMO (it deserves more advertisement).
It seems that we also have a set of nice libraries/bindings in a variety
of domains.

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

These are interesting and important goals.  I'm not sure about the last
item, though, being unfamiliar with Emacs Lisp support in Guile.

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

Of course we can't commit to anything.  Still, it's good if each of us
can say what he'd like to work on in HEAD, and get feedback from others.
It helps find motivation, too.  So far, I think we just hadn't discussed
any plan for 1.9.  So it's good we've opened the debate.  :-)

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel