From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Marco Maggi" Newsgroups: gmane.lisp.guile.user Subject: Re: the future of Guile Date: Wed, 5 Dec 2007 10:01:18 +0100 Message-ID: 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 1196845402 9773 80.91.229.12 (5 Dec 2007 09:03:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2007 09:03:22 +0000 (UTC) To: "guile-user" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Dec 05 10:03:32 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 1IzqAE-0006C2-Ud for guile-user@m.gmane.org; Wed, 05 Dec 2007 10:03:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Izq9y-0004Gp-6F for guile-user@m.gmane.org; Wed, 05 Dec 2007 04:03:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Izq8D-0002cO-1U for guile-user@gnu.org; Wed, 05 Dec 2007 04:01:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Izq8A-0002Ye-Ry for guile-user@gnu.org; Wed, 05 Dec 2007 04:01:24 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Izq8A-0002YI-G7 for guile-user@gnu.org; Wed, 05 Dec 2007 04:01:22 -0500 Original-Received: from relay-pt3.poste.it ([62.241.4.129]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Izq88-0004mp-Lf for guile-user@gnu.org; Wed, 05 Dec 2007 04:01:21 -0500 Original-Received: from poste.it (192.168.144.52) by relay-pt3.poste.it (7.3.122) (authenticated as marco.maggi-ipsu@poste.it) id 4755EA81000027BF for guile-user@gnu.org; Wed, 5 Dec 2007 10:01:18 +0100 X-Sensitivity: 3 X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 83.190.104.102 X-detected-kernel: by monty-python.gnu.org: Solaris 9 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:6332 Archived-At: 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. Call me stupid if you want, but I picked Guile because the G stands for GNU and the E stands for Extensions. I look at the E as a promise: There will always be special interest in making it easy to interface with C. Now I am not sure if it was a good choice. I tried to attract users interested in math software by coding extensions to special numbers and the GSL. I did it for my own interest, not "for Guile". But I failed. I will never know why (maybe it was just a bad idea), but maybe it is because Guile is too slow and the fact that Scheme is a beautiful and featureful language (compared to Octave, for example) is not enough. It is all FUD, yes, but in the last 7 years a lot of people said that "TCL is dead". Lately on comp.lang.tcl they had a discussion on a unified interface for database access; and they are going to do it. This is not being dead. 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... Ludovic, you are doing an incredible amount of work. But everybody's life moves on. How many active Guile developers are there? Or at least developers that are "still here"? How many active ones understand the evaluator? So, how much work is needed to make Guile a good choice "for something"? As a LFE I think that the work needed is less than what is required for a SI. 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? @Stephen Compall: >> 3. For Guile 2.0 backwards compatibility at the C level can >> be broken. Freely. No shame. No blame. > >This message references another message that I can't find: > >http://lists.gnu.org/archive/html/guile-devel/2003-04/msg00076.html [stuff about inclusion of deprecated code] @Neil Jerram: >Disagree, in general. Why should we be arbitrarily awkward? >If there are specific motivations, we should consider those >case by case. How much does it cost never to discard a thing? With a LFE a huge shared library is not "lightweight". Can something be discarded at least in the 1.x -> 2.x transition? With "everything is a SMOB" and "death to structs" something in the interface changes. I am not talking about changing "scm_to_int" and the like, but, for example, if a function to bind a symbol to the class of a SMOB in a selected module is added: the SMOB definition protocol is changed a bit. The same with a function that selects superclasses. More on this later about the limit on SMOB number. @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. The ugly thing for me is that the DEFINE-* must be at top level; I dunno why. This prevented me from trying some automation (I cannot recall which ones now). Generic functions must be mutable and they must be "entry points" in a big graph-like data structure. That is the only way to do it. I think that there is consensus on the idea that generic functions are one of the points of strength of Lisps. The thing I know is that coding a math extension without them would be a nightmare (there is a reason if I have not written my stuff for TCL). @Ludovic Courts >> 2a. It is fine to have both procedures and generic >> functions, but the default for Guile's C coded >> procedures must be primitive generic. > >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. 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... @Ludovic Courts >> 3a. The limit on SMOB type number must be destroyed. > >It's gonna be hard since we have only 8 bits available >currently[...] 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. @Neil Jerram > 3b. Death to structs! IMO they were "an attempt", but the > resulting code is awful (sorry, but can you disagree?). > >Err.. but aren't structs the main part of how GOOPS is >implemented? IMO Guile's structs do nothing that cannot be done better with a good old C struct wrapped by a SMOB. The thing I am sure of is that structs are preventing me from understanding what goes on in "goops.c": too much work is needed to understand the data structures layout. @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. At present I have to do: if (scm_smob_class) scm_c_define("<" SMOB_DESCRIPTION ">", scm_smob_class[SCM_TC2SMOBNUM(gvector_smob_driver)]); but I think that at the public API level I am not required to know what "scm_smob_class" is, let alone "SCM_TC2SMOBNUM". Anyway, that feature is undocumented; so now I have to go back to change all my GOOPS interfaces that wrap SMOBs. But first I have to understand how to register a method that is directly implemented with a compiled procedure: ADD-METHOD! wants Scheme level procedures... If only I could understand where methods are stored... @Stephen Compall >> 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). > >I am not a GC expert, but it is my understanding that as >long as SMOBs can own non-GC-controlled mallocations freed >by the SMOB free function, you need those macros/functions[...] @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. I think that it is the one Kjetil is referring to, but I am not able to find the message in which someone stated that. 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. @Ludovic Courts >> 6. More modularity. > >I think we could almost have one module per C source file, >e.g., `socket', `posix', `filesys', etc. Fine. >(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. @Stephen Compall >> 6c. GMP support should go into a loadable module (do not >> nuke my mailbox, please). > >Er, what would happen if you overflow fixnums? The same very bad things that happen with all the other languages that do not support bignums. A LFE should not depend upon another big thing like GMP (and should not come with bignums embedded), but there are no problems for a SI. What is the probability of overflowing a fixnum while reading a config file like the one of Serveez? @Ludovic Courts >> 6d. Floating point math procedures should go into a loadable >> module. > >Likewise. 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. @Ludovic Courts >> 6e. Records should go into a loadable module. > >SRFI-9 records? They are already in a "loadable" module. :-) If structs are moved into an external shared library, records can go there, too. @Neil Jerram >> 8. Hackability of the core. If nobody understands it... > >Is it really that difficult? How many can say: I understand the evaluator? And GOOPS, as it is now, is beyond what an occasional contributor can understand in a few hours. @Neil Jerram >> 8c. This is for my own ego: yeah, yeah, yeah! Define: >> >> typedef SCM scm_t; >> > >Surely there's an elisp incantation that would make it kiss >SCM for you? Of course! :-) "Marco Maggi" wrote: > 1. TCL has nice programs that allow to distribute single > file auto-extracting-and-running archives holding the > core executable, shared libraries, pure TCL modules and > some data files (search for "tclkit"). @Neil Jerram >I don't think that a programming language should have its >own packaging system. I am not talking about a packaging system like .deb, .rpm, etc. Tclkit is a solution to the application deployment problem. It seems that among Tclers it had a lot of success. @Neil Jerram >> 3. Resurrect SCWM (Scheme Constraints Window Manager). > >I've settled happily on ion2 now. I suspect a WM may be one >of those things that doesn't really need much scripting, so >I'm not sure what SCWM would be aiming at. IMHO Serveez and a WM for X are perfect usage examples for a LFE. I use Fvwm, and its configuration file is yet another pseudo-language that I have to remember. A design choice that makes sense for them, makes sense for Guile as a LFE. -- Marco Maggi "Now feel the funk blast!" Rage Against the Machine - "Calm like a bomb" _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user