From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [r6rs-discuss] Implementors' intentions concerning R6RS Date: Wed, 31 Oct 2007 11:30:31 +0100 Organization: LAAS-CNRS Message-ID: <87d4uvshiw.fsf@laas.fr> 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> <87ir4ow6xv.fsf@ossau.uklinux.net> 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 1193826757 29207 80.91.229.12 (31 Oct 2007 10:32:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 31 Oct 2007 10:32:37 +0000 (UTC) Cc: Elf , Guile Development To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Oct 31 11:32:39 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 1InAsC-0007JK-Du for guile-devel@m.gmane.org; Wed, 31 Oct 2007 11:32:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1InAs2-0005IV-NF for guile-devel@m.gmane.org; Wed, 31 Oct 2007 06:32:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1InArw-0005GU-Ge for guile-devel@gnu.org; Wed, 31 Oct 2007 06:32:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1InAru-0005FL-Jr for guile-devel@gnu.org; Wed, 31 Oct 2007 06:32:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1InArt-0005F0-Kd for guile-devel@gnu.org; Wed, 31 Oct 2007 06:32:13 -0400 Original-Received: from laas.laas.fr ([140.93.0.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1InArq-0000mX-LL for guile-devel@gnu.org; Wed, 31 Oct 2007 06:32:11 -0400 Original-Received: from messiaen.laas.fr (messiaen [IPv6:2001:660:6602:0:230:65ff:fed4:9d20]) by laas.laas.fr (8.13.8/8.13.8) with SMTP id l9VAUS9O014807; Wed, 31 Oct 2007 11:30:28 +0100 (MET) Original-Received: by messiaen.laas.fr (sSMTP sendmail emulation); Wed, 31 Oct 2007 11:30:31 +0100 X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 10 Brumaire an 216 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Neil Jerram , Guile Development , Elf In-Reply-To: <87ir4ow6xv.fsf@ossau.uklinux.net> (Neil Jerram's message of "Tue\, 30 Oct 2007 22\:53\:16 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Spam-Score: -0.001 () NO_RELAYS X-Scanned-By: MIMEDefang at CNRS-LAAS on IPv6:2001:660:6602::2 X-MIME-Autoconverted: from 8bit to quoted-printable by laas.laas.fr id l9VAUS9O014807 X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) 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:6874 Hi, Neil Jerram writes: > ludovic.courtes@laas.fr (Ludovic Court=E8s) 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