From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: the future of Guile Date: Wed, 05 Dec 2007 21:28:56 +0100 Message-ID: <87y7c86g3b.fsf@chbouib.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1196887875 30085 80.91.229.12 (5 Dec 2007 20:51:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2007 20:51:15 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Dec 05 21:51:25 2007 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J01DH-0005AO-9F for guile-user@m.gmane.org; Wed, 05 Dec 2007 21:51:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J01D0-0005ch-Mo for guile-user@m.gmane.org; Wed, 05 Dec 2007 15:51:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J01Cb-0005Ev-Ka for guile-user@gnu.org; Wed, 05 Dec 2007 15:50:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J01CZ-0005D6-Fk for guile-user@gnu.org; Wed, 05 Dec 2007 15:50:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J01CZ-0005Cs-AW for guile-user@gnu.org; Wed, 05 Dec 2007 15:50:39 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J01CY-0004YE-Hn for guile-user@gnu.org; Wed, 05 Dec 2007 15:50:38 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J0147-0000RG-4T for guile-user@gnu.org; Wed, 05 Dec 2007 20:41:55 +0000 Original-Received: from adh419.fdn.fr ([80.67.176.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Dec 2007 20:41:55 +0000 Original-Received: from ludo by adh419.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Dec 2007 20:41:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 139 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: adh419.fdn.fr X-URL: http://www.laas.fr/~lcourtes/ 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: i486-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:H6/e8Twx0D32DJbHvzInzRLyZTo= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6339 Archived-At: Hello, "Marco Maggi" writes: > Pre-answer to all: the most important thing is to make clear > what are the priorities. With a "language for extensions" > (LFE) there are certain priorities, with a "Scheme > implementation" (SI) there are others. I fear that if no > choice is made Guile will be wiped out by other Schemes. It took me some time, but I now think there's no such sharp distinction between "LFE" and "SI". With the LFE paradigm in mind, one thinks about a C application occasionally calling Scheme code. But as you want more extensibility, you rather end up having a Scheme application occasionally calling C code. This is what SIs are about: being able to do the best with Scheme code, while still allowing interfaces with C code. > For Guile we cannot even talk about such a thing; correct me if I am > wrong, but on the Net there are mostly orphaned projects for Guile... I'm not sure about the "mostly", but there's surely a huge amount of orphaned projects, including VMs, compilers and the likes. > How many active Guile developers are there? Or at least developers > that are "still here"? How many active ones understand the evaluator? Neil and Kevin (at least) have been here for a long time, and I'm sure they understands large parts of the project. Now, it's true that few of us are spending a lot of time to actually create new stuff and set a direction. I encourage others to contribute too, but we need this kind of discussion to get an idea of what we're heading to. > As a SI my opinion is that some sort of compiler is a must, > but it is a lot of work (I took a look at Lightning... > there are soooo many opcodes...). You can try to do any > algorithmic stunt to make Guile faster without a compiler, > but will it be enough for someone? An interpreter *can* be much faster than what we have now, and SICP (among others) is here to guide us. > @Ludovic Courts >>> 2. GOOPS always there. >> >>GOOPS is nice at times, but it's also very "unschemey" in >>spirit, [...] > > I am not sure what you mean here. Then I failed to convey my feeling. ;-) It's really a matter of taste: I've become more and more interested in the functional aspect of Scheme (and other languages), and have come to dislike the imperative programming style. > READ is a nice short symbol and everybody knows its meaning > in real life. It should be available for everyone to use as > function name. I do not care if MAKE-PROCEDURE-WITH-SETTER > is not a generic function because it is unlikely that I need > such a name for a method, but READ... Then generic functions are not the right tool. What you want is "(define core-read read)" or something like that. Then you can use the name `read' in your modules for whatever pleases you---and in practice, you may not always need core `read' anyway. > A possible solution is to use the first level SMOBs only for > Guile-defined ones, and change the implementation of the > public API for SMOB definition to use an evolution of my > subordinate SMOB thing. Maybe, I don't have a clear picture of the possible solutions. > @Ludovic Courts >>> 3c. Every SMOB must have a class and an optional list of >>> superclasses, to allow for methods dispatching. >> >>As you noted in a recent post, SMOBs types have an >>associated class when GOOPS is loaded. So what else do you >>want? > > An optional list of superclasses and an interface to bind > the class to a symbol in a module. OK, got it. The latter is easily addressed, by defining said class in your module to `(@ (oop goops) )', though it's admittedly not very elegant. As for the former, well, I dunno. It may have unforeseen implications. > @Ludovic Courts >>Well, `scm_remember_upto_here ()' is rarely need anyway. > > This is Guideline #2 for a LFE. I wrote this because I > recall to have read a discussion about an alternative GC > that does not require it. Right, Boehm's GC is looks for object pointers in registers. > Anyway, remembering "scm_remember_upto_here" is really > annoying. And it is needed almost every time I access the > client data of a custom SMOB. This is strange. I rarely had to use it, and I can't think of a common programming pattern where it's useful. >>(however, we definitely don't want one shared library per >>module, because of the overhead). > > Ugh! The only reason I see to split up is to reduce the size > of the core shared library. Shared libraries add memory overhead as they need to be aligned on page boundaries, symbol lookup overhead, among others. Ulrich Drepper wrote a nice article about the pitfalls of writing DSOs (shared libs) but I can't find it. > The same very bad things that happen with all the other > languages that do not support bignums. ... which is the raison d'être of Scheme's numeric tower. :-) > I am talking about the SIN, COS, TAN, ... functions, the > ones in the Scientific Info node. It is another way of > reducing a bit the size of the core shared library. These are very common procedures, part of R5RS, and you wouldn't gain much by removing them. > If structs are moved into an external shared library, > records can go there, too. Records are too common to be removed from the core: almost everyone would end up loading that module. Thanks, Ludovic. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user