From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: [r6rs-discuss] Implementors' intentions concerning R6RS Date: Tue, 30 Oct 2007 22:53:16 +0000 Message-ID: <87ir4ow6xv.fsf@ossau.uklinux.net> References: <818B5317-4F09-46F3-9376-43292CEB3C16@iro.umontreal.ca> <200710261850.l9QIo8Vu017241@garbo.cs.indiana.edu> <47229C5E.8070406@emf.net> <87640rm7ec.fsf@ossau.uklinux.net> <87hckbkpho.fsf@ossau.uklinux.net> <87d4uykkes.fsf@laas.fr> <87ejfd7fnq.fsf@ossau.uklinux.net> <877il57wyt.fsf@laas.fr> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1193784825 31498 80.91.229.12 (30 Oct 2007 22:53:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2007 22:53:45 +0000 (UTC) Cc: Elf To: Guile Development Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 30 23:53:45 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Imzxr-0006TV-Qi for guile-devel@m.gmane.org; Tue, 30 Oct 2007 23:53:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Imzxi-0000tg-8e for guile-devel@m.gmane.org; Tue, 30 Oct 2007 18:53:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Imzxg-0000tR-4Q for guile-devel@gnu.org; Tue, 30 Oct 2007 18:53:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Imzxf-0000rw-5G for guile-devel@gnu.org; Tue, 30 Oct 2007 18:53:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Imzxf-0000rt-1f for guile-devel@gnu.org; Tue, 30 Oct 2007 18:53:27 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Imzxe-0003T4-DV for guile-devel@gnu.org; Tue, 30 Oct 2007 18:53:26 -0400 Original-Received: from arudy (host86-145-152-23.range86-145.btcentralplus.com [86.145.152.23]) by mail3.uklinux.net (Postfix) with ESMTP id 2A6BE1F7657; Tue, 30 Oct 2007 22:53:18 +0000 (GMT) Original-Received: from laruns (unknown [192.168.0.10]) by arudy (Postfix) with ESMTP id 000E338009; Tue, 30 Oct 2007 22:53:16 +0000 (GMT) In-Reply-To: <877il57wyt.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Tue, 30 Oct 2007 10:50:18 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6871 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) 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.=20=20 > 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