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.user Subject: Re: the future of Guile Date: Tue, 04 Dec 2007 13:41:09 +0100 Organization: LAAS-CNRS Message-ID: <87wsrupr8a.fsf@laas.fr> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196772100 6543 80.91.229.12 (4 Dec 2007 12:41:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Dec 2007 12:41:40 +0000 (UTC) Cc: guile-user To: "Marco Maggi" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Dec 04 13:41:50 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 1IzX5o-0006bX-AT for guile-user@m.gmane.org; Tue, 04 Dec 2007 13:41:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzX5X-00063f-Rd for guile-user@m.gmane.org; Tue, 04 Dec 2007 07:41:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzX5S-00062Z-I7 for guile-user@gnu.org; Tue, 04 Dec 2007 07:41:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzX5P-00060F-RZ for guile-user@gnu.org; Tue, 04 Dec 2007 07:41:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzX5P-00060B-LE for guile-user@gnu.org; Tue, 04 Dec 2007 07:41:15 -0500 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 1IzX5P-0004B3-4L for guile-user@gnu.org; Tue, 04 Dec 2007 07:41:15 -0500 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 lB4Cevw8005481; Tue, 4 Dec 2007 13:40:57 +0100 (MET) Original-Received: by messiaen.laas.fr (sSMTP sendmail emulation); Tue, 04 Dec 2007 13:41:09 +0100 X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 14 Frimaire 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: "Marco Maggi" , "guile-user" In-Reply-To: (Marco Maggi's message of "Tue\, 4 Dec 2007 07\:50\:51 +0100") 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-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) 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:6318 Archived-At: Hi, "Marco Maggi" writes: > But it does not have to because, like it or not, Guile is a > language for extensions. With this in mind... Right, although I question the "language for extensions" paradigm: why would you choose language Y for "extensions" and language X for the rest, given that (i) X sucks, (ii) Y rocks, and (iii) nothing inherently makes programs in language Y "slower". :-) (Of course, language X allows you to re-use lots of libraries and tools, so you definitely don't want to throw it away, but at least you want to reduce the amount of code written in X.) > 3. For Guile 2.0 backwards compatibility at the C level can > be broken. Freely. No shame. No blame. As Stephen suggested, we have to be cautious here. > 2. GOOPS always there. GOOPS is nice at times, but it's also very "unschemey" in spirit, relying on hard-to-follow side-effects for a lot of core operations (see the `define-method' mess in G-Wrap), and biased towards an imperative programming style. I used to be a big fan, but I've become more and more suspicious. > 2a. It is fine to have both procedures and generic > functions, but the default for Guile's C coded > procedures must be primitive generic. Non-primitive > generics are allowed as exceptions (case: READ is a > primitive procedure, dunno why). What would it buy you if `read' were a primitive generic? `write' is certainly useful as a generic, but I don't see the benefit of `read' as a generic. Besides, if turning primitives into primitive-generics doesn't slow down Guile startup, then we can go for it. > 3a. The limit on SMOB type number must be destroyed. It's gonna be hard since we have only 8 bits available currently (BTW, I saw your patch that adds support for sub-SMOBs but it looks complex to me---more on that later). > 3b. Death to structs! IMO they were "an attempt", but the > resulting code is awful (sorry, but can you disagree?). We may have to keep it, at least for the sake of backward compatibility. > 3c. Every SMOB must have a class and an optional list of > superclasses, to allow for methods dispatching. This is > not meant to be an attempt to "corrupt" the concept of > class, but a mean to extend 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? > 4. If a garbage collector allows to remove the need for > "scm_remember_upto_here" it must be adopted even if it > makes Guile slower and it raises memory usage a bit (or > more than a bit). Well, `scm_remember_upto_here ()' is rarely need anyway. > 6. More modularity. I think we could almost have one module per C source file, e.g., `socket', `posix', `filesys', etc. (however, we definitely don't want one shared library per module, because of the overhead). We could them set up a backward-compatible namespace that pulls all of them, while still leaving the opportunity to execute code in a minimal environment where only core primitives are available. > 6c. GMP support should go into a loadable module (do not > nuke my mailbox, please). No way (see Stephen's reply). :-) > 6d. Floating point math procedures should go into a loadable > module. Once they are there, more functions can be added > (from the standard C library and not) and a "long > double" SMOB can be put in, too. Likewise. > 6e. Records should go into a loadable module. SRFI-9 records? They are already in a "loadable" module. :-) > 7a. It makes no sense to discuss if Guile should go R6RS or > not. The only meaningful discussion is about which > hooks are needed in Guile's code to make those features > available as loadable modules. (Yes, this is > difficult). Agreed. > 8a. Ludovic, do you still have that patch that reduces the > size of the evaluator? I do not want to hurt anyone's > feelings, but I do not understand why it was rejected. It did not really make it smaller, it just splitted it into several parts. The main arguments against it were that it splitted things badly and that moving code around precludes auditing through diffs: http://lists.gnu.org/archive/html/guile-devel/2007-02/msg00040.html > 8b. There are struct types in the core whose name is not > prefixed with "scm_t_" (example: scm_metaclass_standard) > this should be fixed. Right. > 8c. This is for my own ego: yeah, yeah, yeah! Define: > > typedef SCM scm_t; > > Emacs font locking kisses "scm_t" automatically. I'm afraid it's a bit too late, and we don't want two names for one thing. Thanks, Ludovic. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user