From: Neil Jerram <neil@ossau.uklinux.net>
To: Guile Development <guile-devel@gnu.org>
Cc: Elf <elf@ephemeral.net>
Subject: Re: [r6rs-discuss] Implementors' intentions concerning R6RS
Date: Tue, 30 Oct 2007 22:53:16 +0000 [thread overview]
Message-ID: <87ir4ow6xv.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <877il57wyt.fsf@laas.fr> (Ludovic Courtès's message of "Tue, 30 Oct 2007 10:50:18 +0100")
ludovic.courtes@laas.fr (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
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2007-10-30 22:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <818B5317-4F09-46F3-9376-43292CEB3C16@iro.umontreal.ca>
[not found] ` <200710261850.l9QIo8Vu017241@garbo.cs.indiana.edu>
[not found] ` <Pine.LNX.4.61.0710261701241.9685@tesseract.thetesseract.org>
[not found] ` <47229C5E.8070406@emf.net>
[not found] ` <Pine.LNX.4.61.0710280508300.19352@tesseract.thetesseract.org>
2007-10-28 18:16 ` [r6rs-discuss] Implementors' intentions concerning R6RS Neil Jerram
2007-10-28 18:29 ` Elf
[not found] ` <Pine.LNX.4.61.0710281146460.32075@tesseract.thetesseract.org>
2007-10-28 19:28 ` Neil Jerram
2007-10-29 15:30 ` Ludovic Courtès
2007-10-29 21:51 ` Neil Jerram
2007-10-30 9:50 ` Ludovic Courtès
2007-10-30 15:01 ` Julian Graham
2007-10-30 23:15 ` Neil Jerram
2007-10-31 14:55 ` Julian Graham
2007-10-31 13:12 ` Ludovic Courtès
2007-11-06 21:54 ` Neil Jerram
2007-11-11 15:28 ` Ludovic Courtès
2007-11-12 20:29 ` Neil Jerram
2007-11-12 20:51 ` Ludovic Courtès
2007-10-30 22:53 ` Neil Jerram [this message]
2007-10-31 10:30 ` Ludovic Courtès
2007-11-02 20:53 ` Klaus Schilling
2007-11-03 11:14 ` Ludovic Courtès
2007-11-03 17:49 ` Klaus Schilling
2007-10-30 23:55 ` Andy Wingo
2007-11-03 18:15 ` Klaus Schilling
2007-11-04 12:39 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ir4ow6xv.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=elf@ephemeral.net \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).