From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.user Subject: Re: the future of Guile Date: Thu, 06 Dec 2007 00:11:35 +0100 Message-ID: <87ir3c20uw.fsf@pobox.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196896347 27833 80.91.229.12 (5 Dec 2007 23:12:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2007 23:12:27 +0000 (UTC) Cc: guile-user To: "Marco Maggi" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Dec 06 00:12:35 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 1J03Pv-0003Mk-63 for guile-user@m.gmane.org; Thu, 06 Dec 2007 00:12:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J03Pe-0008Fi-AR for guile-user@m.gmane.org; Wed, 05 Dec 2007 18:12:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J03P2-0007a7-3j for guile-user@gnu.org; Wed, 05 Dec 2007 18:11:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J03P1-0007Yg-Ce for guile-user@gnu.org; Wed, 05 Dec 2007 18:11:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J03P1-0007YS-5x for guile-user@gnu.org; Wed, 05 Dec 2007 18:11:39 -0500 Original-Received: from ambient.dashsystems.com ([216.27.85.7] helo=kettle.ambient-hosting.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J03P0-0000Wq-MM for guile-user@gnu.org; Wed, 05 Dec 2007 18:11:38 -0500 Original-Received: from localhost.localdomain (ambient-hosting.net [10.1.6.1]) by kettle.ambient-hosting.net (Postfix) with ESMTP id 25A89880DB; Wed, 5 Dec 2007 18:11:37 -0500 (EST) Original-Received: by localhost.localdomain (Postfix, from userid 1000) id F3095118221; Thu, 6 Dec 2007 00:11:35 +0100 (CET) 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.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:6346 Archived-At: Greets, I have had sufficient wine to respond. On Tue 04 Dec 2007 07:50, "Marco Maggi" writes: > I think that it is time for a chat on the future of Guile. Sure, why not. (Stop justifying your emails, it looks stupid in fixed-width fonts.) > [Guile] does not have to [compete] because, like it or not, Guile is a > language for extensions. Totally. This is what defines guile. (Making it a good standalone scheme is another goal.) > 3b. Death to structs! IMO they were "an attempt", but the > resulting code is awful (sorry, but can you disagree?). No, I cannot :) But solving this would go to solving a lot of your other points. Record types are the hip disjoint type in Schemeland, and you certainly need a way to deal with them from Guile. Structs might not be it, but you will need something smarter than SMOBs... Suggestions? > 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). Who cares? I have written thousands and thousands of lines of guile extensions in C. I have not yet had to use this. Perhaps it's just dumb luck or something. > 5. Guile must be loadable/unloadable as a shared library. > Use case: once I have read a configuration file or a sexp > data file, I do not need it anymore. If you aren't running your app with Guile extensions / code, you don't need a whole scheme interpreter to read s-expressions... > 6. More modularity. Sure, but any breaking of Guile into modules without thinking about syncase is half-baked. This is one bit that r6rs definitely got right IMO. > 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). Oh, I don't know. Standards are definitely relevant, whether it's ERR5RS or R6RS or whatever. The guile hacker community is a small part of the scheme hacker community, we should cooperate if at all possible. In summary, may I unfairly caricature your attitude: "Guile does not follow a number of 'modern' norms, and therefore we should update it." Unfortunately for you Guile is widely deployed and coded to; those users also define "what guile is". Radical changes to the C interface are not going to be forthcoming. Just another Guile hacker, Andy -- http://wingolog.org/ _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user