* Roadmap and goals? @ 2002-04-17 12:21 Tanel Tammet 2002-04-17 20:59 ` Neil Jerram ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Tanel Tammet @ 2002-04-17 12:21 UTC (permalink / raw) Hi, This here looks like a troll, but it isn't. I am sure the same question is asked now and then. I looked through the site and part of email archives, but could not find answers to my questions there. Hence I am trying my luck with the mailing list :-) Basically, I am wondering if anybody could tell me something about the Guile development goals and roadmap: what are the short-term goals, what are the long-term goals, what are the priorities (I mean concrete issues, not just the abstract goal of being a good extension language). I am asking since I was considering whether I could possibly help with the development work. To do that, I'd have to understand where is the Guile development moving, what are the prioritized goals, crucial principles, etc. What would be the projects inside Guile where a person like me could possibly help. Some background: I am the original author of the Hobbit Scheme->C compiler for SCM and although I did not work on improving it for some years, I have recently taken it up again and worked a little on Hobbit and SCM with Aubrey. I plan to continue making small improvements for Hobbit for SCM. I can understand the scope and goals of SCM and what are the issues with which I could possibly help. I am pretty happy with SCM. I have looked briefly into bigloo and other systems, and there are many cool things here and there. However, I cannot really understand (*) what is the driving force behind Guile and (*) what are the specific benefits of using Guile. For example, why exactly should somebody use Guile instead of SCM or Bigloo: what are the specific advantages and what is the downside. Why not use just SCM or Bigloo (they are faster, you know :-) There have to be answers to this question, just that I do not know the answers. In my brief encounters with other people using scheme these issues have come up now and then. I guess it would benefit not only me but the Guile development and acceptance on a wider scale if such guides, policies, roadmaps etc existed and were easy to locate. Regards, Tanel Tammet _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-17 12:21 Roadmap and goals? Tanel Tammet @ 2002-04-17 20:59 ` Neil Jerram 2002-04-18 8:37 ` Panagiotis Vossos ` (2 more replies) 2002-04-18 0:57 ` Christopher Cramer ` (2 subsequent siblings) 3 siblings, 3 replies; 21+ messages in thread From: Neil Jerram @ 2002-04-17 20:59 UTC (permalink / raw) Cc: guile-devel >>>>> "Tanel" == Tanel Tammet <tammet@staff.ttu.ee> writes: Tanel> I am sure the same question is asked now and then. Tanel> I looked through the site and part of email archives, Tanel> but could not find answers to my questions there. Tanel> Basically, I am wondering if anybody could tell Tanel> me something about the Guile development goals Tanel> and roadmap: what are the short-term goals, Tanel> what are the long-term goals, what are the priorities Tanel> (I mean concrete issues, not just the abstract Tanel> goal of being a good extension language). I'd say the answers are largely determined by the interests and priorities of the developers active at any time, as influenced by what interested users ask for. I don't know if there is an official roadmap ... Some of the things that interest me are: documentation, both manual and online; debugging facilities; Emacs integration; libguile factorization; Elisp translation. Tanel> I am asking since I was considering whether I Tanel> could possibly help with the development work. Tanel> To do that, I'd have to understand where is Tanel> the Guile development moving, what are the prioritized Tanel> goals, crucial principles, etc. What would be Tanel> the projects inside Guile where a person Tanel> like me could possibly help. Well, one longer-term focus is reworking Guile's evaluation model to support interesting kinds of compilation -- I guess you'd be pretty helpful in that department. However, in line with the logic above, what might work better would be for you to poke around a bit and then form your own view of what interests you. Tanel> I am pretty happy with SCM. I have looked Tanel> briefly into bigloo and other systems, and Tanel> there are many cool things here and there. Tanel> However, I cannot really understand Tanel> (*) what is the driving force behind Guile and Tanel> (*) what are the specific benefits of using Guile. For me I think the answers are (i) because it's GNU (ii) because it's what I'm now familiar with, which makes me inclined to stick at it until we get it right. Plus in all the things that I've tried to do with it, I've not yet hit any insurmountable technical or philosophical barrier - it mostly "just works." Allegedly Guile is good for integration with C projects, but to be honest I haven't evaluated the competition. Tanel> In my brief encounters with other people Tanel> using scheme these issues have come up Tanel> now and then. (A point for the wider Scheme community ...) Guile has more SRFI support than any of the implementations mentioned on the SRFI web pages (including Guile itself - someone should get that updated...). Tanel> I guess it would benefit not only me Tanel> but the Guile development and acceptance Tanel> on a wider scale if such guides, policies, Tanel> roadmaps etc existed and were easy to locate. Perhaps, but would they be real, or just hype? Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-17 20:59 ` Neil Jerram @ 2002-04-18 8:37 ` Panagiotis Vossos 2002-04-19 9:14 ` Panagiotis Vossos 2002-04-18 14:58 ` bitwize 2002-04-20 7:23 ` Thien-Thi Nguyen 2 siblings, 1 reply; 21+ messages in thread From: Panagiotis Vossos @ 2002-04-18 8:37 UTC (permalink / raw) Cc: guile-devel Neil Jerram <neil@ossau.uklinux.net> writes: > (A point for the wider Scheme community ...) Guile has more SRFI > support than any of the implementations mentioned on the SRFI web > pages (including Guile itself - someone should get that updated...). Just sent them an email asking to add a guile entry mentioning the srfi's documented in 1.5.6 manual. panagiotis _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-18 8:37 ` Panagiotis Vossos @ 2002-04-19 9:14 ` Panagiotis Vossos 2002-04-20 6:58 ` Thien-Thi Nguyen 0 siblings, 1 reply; 21+ messages in thread From: Panagiotis Vossos @ 2002-04-19 9:14 UTC (permalink / raw) Cc: Neil Jerram, guile-devel Panagiotis Vossos <jacbre@internet.gr> writes: > Neil Jerram <neil@ossau.uklinux.net> writes: > > > (A point for the wider Scheme community ...) Guile has more SRFI > > support than any of the implementations mentioned on the SRFI web > > pages (including Guile itself - someone should get that updated...). > > Just sent them an email asking to add a guile entry mentioning the > srfi's documented in 1.5.6 manual. Entry updated. The only problem now is that they have linked to the main guile page, where there is no reference to version 1.5.6. panagiotis _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-19 9:14 ` Panagiotis Vossos @ 2002-04-20 6:58 ` Thien-Thi Nguyen 2002-04-20 10:18 ` Panagiotis Vossos 0 siblings, 1 reply; 21+ messages in thread From: Thien-Thi Nguyen @ 2002-04-20 6:58 UTC (permalink / raw) Cc: guile-devel From: Panagiotis Vossos <jacbre@internet.gr> Date: Fri, 19 Apr 2002 12:14:35 +0300 Entry updated. The only problem now is that they have linked to the main guile page, where there is no reference to version 1.5.6. this page has been updated recently to have that info: http://www.gnu.org/software/guile/ is this the page you refer to? thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-20 6:58 ` Thien-Thi Nguyen @ 2002-04-20 10:18 ` Panagiotis Vossos 0 siblings, 0 replies; 21+ messages in thread From: Panagiotis Vossos @ 2002-04-20 10:18 UTC (permalink / raw) Cc: guile-devel Thien-Thi Nguyen <ttn@giblet.glug.org> writes: > From: Panagiotis Vossos <jacbre@internet.gr> > Date: Fri, 19 Apr 2002 12:14:35 +0300 > > Entry updated. The only problem now is that they have linked to the > main guile page, where there is no reference to version 1.5.6. > > this page has been updated recently to have that info: > > http://www.gnu.org/software/guile/ > > is this the page you refer to? Sorry, my mistake. They have linked to http://www.gnu.org/software/guile/guile.html, from which you can find 1.5.6 via the recent news link. panagiotis _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-17 20:59 ` Neil Jerram 2002-04-18 8:37 ` Panagiotis Vossos @ 2002-04-18 14:58 ` bitwize 2002-04-18 19:26 ` Rob Browning 2002-04-20 7:23 ` Thien-Thi Nguyen 2 siblings, 1 reply; 21+ messages in thread From: bitwize @ 2002-04-18 14:58 UTC (permalink / raw) On 17 Apr 2002, Neil Jerram wrote: > > Some of the things that interest me are: documentation, both manual > and online; debugging facilities; Emacs integration; libguile > factorization; Elisp translation. It may be too much to ask, but I'd like to see a VM being integrated into guile-core. The one that Keisuke Nishida wrote a while back is supposedly really good; integrating it so that byte-compilation and execution of bytecodes becomes the default method of interpretation and execution (much as it is with mzscheme) would be a Good Thing for Guile, performance-wise. Another thing is, I use Guile where many hackers would choose Perl or Python, as an all-purpose automation and glue language. It's there, it works, and Scheme is much easier to write things quickly in than those other languages. Anything that boosts Guile from a systems integration standpoint would be nice for my uses. Responding to .NET, SOAP, and all that hype-based hoopla with efficient Scheme-based simple RPC and secure mobile code mechanisms would be nifty. That's my wish list for the time being. The TODO also mentions a decent Guile binding for Tk. I'm currently working on this using pTk; has anyone gotten any further? > For me I think the answers are (i) because it's GNU (ii) because it's > what I'm now familiar with, which makes me inclined to stick at it > until we get it right. Plus in all the things that I've tried to do > with it, I've not yet hit any insurmountable technical or > philosophical barrier - it mostly "just works." The fact that "it's GNU" is perhaps instrumental to Guile's success. Scheme has overall been slapped with the Pascal stigma: it's an "educational language", which means it lacks utility in the Real World. Guile represents disproof by counterexample, by being quite central to many of the things GNU is doing (GNOME, etc.). > Allegedly Guile is good for integration with C projects, but to be > honest I haven't evaluated the competition. SIOD may actually be better in this regard, because of its tiny size and liberal license. But then again, SIOD lacks RnRS compliance, and much of the other niftiness that Guile has. -- Jeffrey T. Read "LOBSTER STICKS TO MAGNET!" _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-18 14:58 ` bitwize @ 2002-04-18 19:26 ` Rob Browning 0 siblings, 0 replies; 21+ messages in thread From: Rob Browning @ 2002-04-18 19:26 UTC (permalink / raw) Cc: guile-devel bitwize@wizards-of-source.org writes: > It may be too much to ask, but I'd like to see a VM being integrated > into guile-core. The one that Keisuke Nishida wrote a while back is > supposedly really good; integrating it so that byte-compilation and > execution of bytecodes becomes the default method of interpretation > and execution (much as it is with mzscheme) would be a Good Thing > for Guile, performance-wise. A VM is possible, but see the other recent notes on what probably needs to happen first, in particular Marius' (and my) recent mails about the macro system, module system cleanups, etc. > Responding to .NET, SOAP, and all that hype-based hoopla with > efficient Scheme-based simple RPC and secure mobile code mechanisms > would be nifty. One thing you might want to check out is ice-9/safe.scm if you haven't looked at it yet. It's not what you're talking about above, but it does allow you to create environments where it's supposed to be safe to eval random-untrusted-code and have very careful control over what it could possibly do. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-17 20:59 ` Neil Jerram 2002-04-18 8:37 ` Panagiotis Vossos 2002-04-18 14:58 ` bitwize @ 2002-04-20 7:23 ` Thien-Thi Nguyen 2 siblings, 0 replies; 21+ messages in thread From: Thien-Thi Nguyen @ 2002-04-20 7:23 UTC (permalink / raw) Cc: tammet, guile-devel From: Neil Jerram <neil@ossau.uklinux.net> Date: 17 Apr 2002 21:59:07 +0100 Perhaps, but would they be real, or just hype? the real questions are: what is the mechanism for distinguishing these two? who will write that Program? who will execute that Protocol? can these be defined soon? these last two are hardest to do. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-17 12:21 Roadmap and goals? Tanel Tammet 2002-04-17 20:59 ` Neil Jerram @ 2002-04-18 0:57 ` Christopher Cramer 2002-04-19 17:36 ` Marius Vollmer 2002-04-19 8:38 ` Nicolas Neuss 2002-04-20 7:47 ` Thien-Thi Nguyen 3 siblings, 1 reply; 21+ messages in thread From: Christopher Cramer @ 2002-04-18 0:57 UTC (permalink / raw) Cc: guile-devel On Wed, Apr 17, 2002 at 03:21:47PM +0300, Tanel Tammet wrote: > To do that, I'd have to understand where is > the Guile development moving, what are the prioritized > goals, crucial principles, etc. What would be > the projects inside Guile where a person > like me could possibly help. There's some stuff in CVS discussing this, e.g.: http://savannah.gnu.org/cgi-bin/viewcvs/guile/guile/workbook/policy/plans.text?rev=1.1&content-type=text/vnd.viewcvs-markup http://savannah.gnu.org/cgi-bin/viewcvs/guile/guile/workbook/tasks/TODO?rev=1.33&content-type=text/vnd.viewcvs-markup > For example, why exactly should somebody > use Guile instead of SCM or Bigloo: > what are the specific advantages and > what is the downside. Why not use just > SCM or Bigloo (they are faster, you know :-) > There have to be answers to this question, > just that I do not know the answers. I haven't checked out SCM in a long time, so there is a slight possibility this isn't true anymore, but the advantage Guile has over SCM is that integration with C is much easier. There was some reason why I decided to use Guile instead of Bigloo, but I really can't remember what it was anymore. I know SCM is a little faster than Guile, but I was not under the impression that Bigloo was. -- Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/> Quoi que vous fassiez, écrasez l'infâme, et aimez qui vous aime. -- Voltaire _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-18 0:57 ` Christopher Cramer @ 2002-04-19 17:36 ` Marius Vollmer 0 siblings, 0 replies; 21+ messages in thread From: Marius Vollmer @ 2002-04-19 17:36 UTC (permalink / raw) Cc: Tanel Tammet, guile-devel Christopher Cramer <crayc@pyro.net> writes: > There's some stuff in CVS discussing this, e.g.: > [...] There is also http://savannah.gnu.org/cgi-bin/viewcvs/guile/guile/workbook/policy/goals.text?rev=1.1&content-type=text/vnd.viewcvs-markup which is less specific and therefore less out-dated. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-17 12:21 Roadmap and goals? Tanel Tammet 2002-04-17 20:59 ` Neil Jerram 2002-04-18 0:57 ` Christopher Cramer @ 2002-04-19 8:38 ` Nicolas Neuss 2002-04-21 15:14 ` Rob Browning 2002-04-21 22:26 ` bitwize 2002-04-20 7:47 ` Thien-Thi Nguyen 3 siblings, 2 replies; 21+ messages in thread From: Nicolas Neuss @ 2002-04-19 8:38 UTC (permalink / raw) Cc: guile-devel Dear Guilers. Motivated by the recent message from Tanel Tammet on the guile-devel mailing list (and the answers, which are IMO unsatisfactory), I want to present also my point of view on Guile. First, let me tell a little bit of my own history. I was a C programmer who searched an extension language for an application. First, I thought about using Elisp (having immediately an integration with the editor). Thus I wrote to Stallman and asked him about this, and, of course, he suggested Guile. I came to Guile in 1998. Maintainer was Jim Blandy at that time. Somewhat later he gave up, was followed by Maciej Stachowiak, who was joined by other developers (Mikael Djurfeldt, Michael Livshin, and Marius Vollmer, if I remember correctly). Who is maintainer now? I don't know precisely, because I read the Guile mailing list only superficially since the year 2000. Now, what are Guile's goals? IMO, Guile arose from several ideas of RMS: the first that Lisp-like languages are best, the second that combining several languages (i.e. using extension languages as he did with Emacs) is the way to go, the third that Elisp should be replaced by Scheme, and the fourth that such software has to be under the GPL and maintained by the FSF. During the so-called TCL flamewar, a fifth idea was brought up, namely that the FSF extension language should emulate others. Unfortunately, all those goals are very questionable. First, non-lisp languages get more and more of Lisp's capabilities[1] and the advantage is not large any more, especially for the spartanic Scheme branch. Second, my guess is that most applications are written within one language, because maintaining the interface between two languages is a problem. Third, replacing Elisp with Common Lisp would probably be both easier and better (but is still difficult, see below). Fourth, more liberal licenses than the GPL (e.g. some BSD license) or GPLed software not maintained by the FSF is also a nice thing[2]. Fifth, emulating languages in an integrating way is easy to say, but difficult to work out (this is proved by Guile not emulating one single other language in a reasonable way). Where does Guile stand now? In my eyes, Guile is fighting on a lost position. I will elaborate a little bit on this in the following. First, there are several strong and healthy Schemes competing. I don't know about SCM and Bigloo which the previous poster suggested, but I know a little about PLT Scheme. This Scheme has an IDE making it work under Windows, Mac and Unix very nicely. And a lot of work is put into it from several people at several universities (Matthias Felleisen, Shriram Krishnamurti, ...). [One can look at this as unfair competition because Guile has no such direct university support. But that doesn't count, at least for me as a user.] Its license is even more liberal than the GPL, and therefore could be accepted IMO. Second, I have serious doubts that Scheme as a language succeeds (in spite of PLT Scheme). It is quite astonishing that at this time a language is propagated as the ultimate weapon, which has neither OO support nor modules/namespaces in a standardized way. It seems that the Scheme dogma of accepting only perfect solutions approaches now a boundary where only several 90% solutions are available, and thus cannot be extended further. Even inside the Lisp language family, Scheme looses against (ANSI) Common Lisp which supplies both a very strong OO system and packages in a standardized way. There are also good and free CL implementations, namely CLISP (GPL, only byte-compilation, very portable) and CMUCL (public domain, compilation to native code, less portable). [3] [Third, of course, it is questionable if Lisp itself will survive, because the Lisp family as a whole is attacked by other languages like Java, C++, ML, Smalltalk/Squeak, ... But there were Kassandras for Lisp all the time during its long life.] What should Guile do? In my opinion, there should be a drastic change in direction. First, of course, you should finish the current ?1.6? release as fast as possible. But then you should evaluate several other Scheme implementations, as well as CLISP and CMUCL. If it should turn out that Guile has enough merits (apart from the merit that it's the Scheme you know), fine, forget my words. If not, you should talk seriously to RMS. Because then it is time to rethink this project and take appropriate actions. These actions may go from joining with SCM on the one side[4] to shifting the whole project towards Common Lisp as extension language on the other side (leaving the domain "Scheme as an educational language" to PLT Scheme). Concerning Elisp replacement, it would make sense to drop Scheme in favor of CLISP, too. This would make the project much easier, because CL and Elisp are comparatively near (especially when you do (require 'cl) in Emacs:-). Further, there are Emacs-like editors written in CL, see Hemlock for CMUCL from which one could maybe take some code. Also, there may be CL people willing to help, even Erik Naggum (see footnote) once planned something like that. One should keep in mind, that it is still a hairy project[5]. But it could succeed, if Stallman pushed it. That's all I have to say. What concerns myself, I have switched to Common Lisp about two years ago. I guess, I'll drop out of the Guile mailing list soon. I want to thank the people that were and are on this list. I learned a lot of things, but I prefer another playground now. Goodbye, Nicolas. [1] see the web page of Paul Graham at <http://www.paulgraham.com/articles.html> [2] It seems that while the GNU system being under the GPL is certainly achievable, it does not really work that the FSF is the copyright hodler of all essential parts. This goal should be abandoned. [3] I do not mention GCL here, because it is not ANSI compliant, and appears not to be actively developed any more. It seems to be one of those projects where you have to tell people NOT to use the FSF version (similar to the Hurd kernel, and maybe Guile). [4] IMHO, it is a terrible nonsense that people work on so many Scheme implementations in parallel, only to feed the egos of their respective leaders. [5] See the articles on this topic at the Xemacs web site http://www.xemacs.org/Architecting-XEmacs/index.html . P.S.2: If some of you did not yet look at CL, you could start with reading comp.lang.lisp. [You will meet several other (former) Guilers there:-).] But when joining that newsgroup, please remember the following things: 1. It is about (Common) Lisp, not about Scheme. Scheme has an own newsgroup (comp.lang.scheme). 2. Many burning questions (why is () equal to #f?, why are there two namespaces?, replacing Elisp, ... and so on) have already been discussed, most of them several times. You can find such info in the FAQ <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/top.html> or via Google group search <http://groups.google.com/groups?selm=>. 3. There is a guy called Erik Naggum who is very rude. Nevertheless, he is one of the sharpest guy I know, and you do everyone a favor if you keep that in mind. Don't get into a struggle with him, those exchanges are extremely annoying. 4. As with every newsgroup or mailing list, you should read it for some time without posting. In parallel, you should read an introductory book (I'd recommend Graham's "ANSI Common Lisp"). And install the Common Lisp Hyperspec (because of this tremendous thing, documentation is not a problem with CL). P.S.2: I thought about sending this also to guile-user@gnu.org. I refrained from doing so, because Tamel did not do that, and because I do not want to be too destructive. But IMHO, also users should know about these problems in Guile's design. So, it remains for you maintainers to inform them... _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-19 8:38 ` Nicolas Neuss @ 2002-04-21 15:14 ` Rob Browning 2002-04-21 22:26 ` bitwize 1 sibling, 0 replies; 21+ messages in thread From: Rob Browning @ 2002-04-21 15:14 UTC (permalink / raw) Cc: Tanel Tammet, guile-devel (including guile-user since a copy was posted there too) Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes: > Unfortunately, all those goals are very questionable. First, non-lisp > languages get more and more of Lisp's capabilities[1] and the > advantage is not large any more, especially for the spartanic Scheme > branch. Even if that were true, to me that's a little like saying that there's no reason Perl programmers shouldn't switch to Python, or Tcl to Perl, or ... since they can do roughly the same things (presuming the languages in question can do mostly the same things). > Second, my guess is that most applications are written within one > language, because maintaining the interface between two languages is > a problem. Could be, and it deppends on what you mean bu "written within" but to me the Gimp, Guppi, Gnucash, Emacs, snd, and Gnumeric are notable counter-examples. > Third, replacing Elisp with Common Lisp would probably be both > easier and better (but is still difficult, see below). I haven't checked, but I'd be a little concerned about size. Last CL implementation I looked at in much detail was quite large, but perhaps that's not true anymore. > Fourth, more liberal licenses than the GPL (e.g. some BSD license) > or GPLed software not maintained by the FSF is also a nice thing[2]. Not sure if you know, but Guile's license has changed, it's no longer covered under the GPL alone, there's an exception clause that allows it to be linked against other applications without causing them to automatically be covered under the GPL. See the Guile copyright for the precise terms. > Fifth, emulating languages in an integrating way is easy to say, but > difficult to work out (this is proved by Guile not emulating one > single other language in a reasonable way). I consider this an open question -- guile may or may not ever end up emulating a large number of languages other than elisp, but after the recent work, I do have reasonable hope for elisp. <shrug>, we'll see. > [2] It seems that while the GNU system being under the GPL is > certainly achievable, it does not really work that the FSF is the > copyright hodler of all essential parts. This goal should be > abandoned. I can't speak for RMS, but based on my experience, this is a non-starter, and now that I understand the issues and have seen the US legal system in action, I can understand the reasoning. > [4] IMHO, it is a terrible nonsense that people work on so many Scheme > implementations in parallel, only to feed the egos of their > respective leaders. You and me both -- what other possible reason could people have for working on anything but Guile? ;> -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-19 8:38 ` Nicolas Neuss 2002-04-21 15:14 ` Rob Browning @ 2002-04-21 22:26 ` bitwize 2002-04-22 18:36 ` Kirill Lisovsky 1 sibling, 1 reply; 21+ messages in thread From: bitwize @ 2002-04-21 22:26 UTC (permalink / raw) Cc: Tanel Tammet, guile-devel On 19 Apr 2002, Nicolas Neuss wrote: > Unfortunately, all those goals are very questionable. First, non-lisp > languages get more and more of Lisp's capabilities[1] and the > advantage is not large any more, especially for the spartanic Scheme > branch. Second, my guess is that most applications are written within > one language, because maintaining the interface between two languages > is a problem. Third, replacing Elisp with Common Lisp would probably > be both easier and better (but is still difficult, see below). > Fourth, more liberal licenses than the GPL (e.g. some BSD license) or > GPLed software not maintained by the FSF is also a nice thing[2]. > Fifth, emulating languages in an integrating way is easy to say, but > difficult to work out (this is proved by Guile not emulating one > single other language in a reasonable way). What about .NET? :) (Actually, this too is proof of your point; in order to shoehorn certain languages, such as Perl and even Visual Basic, into .NET's architecture some pretty significant changes had to be made to these languages' syntaxes and paradigms.) This hacker couldn't care less about the ideology and motivation behind Guile. Perl and Tcl annoy me, but Guile is fun and it's useful, and I can quickly hack up workable programs with it that would have taken quite a long time with another language. (I once wrote a fairly complete, albeit non-validating, XML parser in Guile over an evening or two.) It is for these reasons that I joined guile-devel not too long ago (after lurking on guile-user for X years): I want to help keep Guile strong. > Where does Guile stand now? In my eyes, Guile is fighting on a lost > position. I will elaborate a little bit on this in the following. I disagree with this position. There are many things that Guile has going for it. > Second, I have serious doubts that Scheme as a language succeeds (in > spite of PLT Scheme). It is quite astonishing that at this time a > language is propagated as the ultimate weapon, which has neither OO > support nor modules/namespaces in a standardized way. It seems that > the Scheme dogma of accepting only perfect solutions approaches now a > boundary where only several 90% solutions are available, and thus > cannot be extended further. Even inside the Lisp language family, > Scheme looses against (ANSI) Common Lisp which supplies both a very > strong OO system and packages in a standardized way. There are also > good and free CL implementations, namely CLISP (GPL, only > byte-compilation, very portable) and CMUCL (public domain, compilation > to native code, less portable). [3] As I mentioned before, the fact that "it's GNU" means a great deal to Guile. There are a lot of disparate variations of Scheme out there, that's true. (Some, such as SIOD, call themselves Scheme but don't adhere to any published Scheme standard.) Part of Scheme's problem is its Pascal stigma: it's an "educational" language, so no one will use it for any *real* work, so why not slap your own umpteenth extension on it. Even though Guile is Scheme, it possesses some really robust APIs, particularly in the string handling, file, and networking side of things, that make it useful for real-world tasks. It is also central to several GNU projects, including TeXmacs and GNOME. Because it is a living, functional part of the GNU project, Guile is well suited to shake off the Pascal stigma and *become* a sort of de facto standard, one whose APIs and paradigms other Schemes hopefully will emulate. The SRFI process, which helps crystallize the Scheme community around some good ideas and provide implementations that work across Schemes, is a step in the right direction. Maybe more Guile hackers should contribute SRFIs that encapsulate Guile's strong points. > [Third, of course, it is questionable if Lisp itself will survive, > because the Lisp family as a whole is attacked by other languages like > Java, C++, ML, Smalltalk/Squeak, ... But there were Kassandras for > Lisp all the time during its long life.] LISP has a lot of things going for it too, but I don't want to start an advocacy flamewar. LISPers see enough advantages in LISP that Perl, Smalltalk, Java, et al. have yet to match in any significant way. "Those who do not understand LISP are doomed to reimplement it, poorly." :) We could debate the technical points all we like, but LISP has an ineffable nature about it that most other languages lack... or maybe no programmer has yet effed it in a suitable manner. In contrast I find Perl's nature to be quite effable; I find myself frequently muttering, "This effing syntax..." :) My point is that LISP (and by extension, Scheme (and by extension, Guile)) is more than the sum of its parts and will remain a strong language for a variety of applications. > What should Guile do? In my opinion, there should be a drastic change > in direction. First, of course, you should finish the current ?1.6? > release as fast as possible. But then you should evaluate several > other Scheme implementations, as well as CLISP and CMUCL. If it > should turn out that Guile has enough merits (apart from the merit > that it's the Scheme you know), fine, forget my words. If not, you > should talk seriously to RMS. Because then it is time to rethink this > project and take appropriate actions. These actions may go from > joining with SCM on the one side[4] to shifting the whole project > towards Common Lisp as extension language on the other side (leaving > the domain "Scheme as an educational language" to PLT Scheme). AFAIK Guile is a derivative, and extension, of SCM. SCM's goals appear to be different from Guile's. > Concerning Elisp replacement, it would make sense to drop Scheme in > favor of CLISP, too. This would make the project much easier, because > CL and Elisp are comparatively near (especially when you do (require > 'cl) in Emacs:-). Further, there are Emacs-like editors written in > CL, see Hemlock for CMUCL from which one could maybe take some code. > Also, there may be CL people willing to help, even Erik Naggum (see > footnote) once planned something like that. One should keep in mind, > that it is still a hairy project[5]. But it could succeed, if > Stallman pushed it. There are Emacs-like editors written in Scheme too: see MIT Scheme's Edwin. :) > That's all I have to say. What concerns myself, I have switched to > Common Lisp about two years ago. I guess, I'll drop out of the Guile > mailing list soon. I want to thank the people that were and are on > this list. I learned a lot of things, but I prefer another playground > now. Sorry to see you go. That's the way these things go, I guess. -- Jeffrey T. Read "LOBSTER STICKS TO MAGNET!" _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-21 22:26 ` bitwize @ 2002-04-22 18:36 ` Kirill Lisovsky 2002-04-23 7:53 ` rm 0 siblings, 1 reply; 21+ messages in thread From: Kirill Lisovsky @ 2002-04-22 18:36 UTC (permalink / raw) Cc: Nicolas Neuss, Tanel Tammet, guile-devel On Mon, 22 Apr 2002 bitwize@wizards-of-source.org wrote: > long time with another language. (I once wrote a fairly complete, albeit > non-validating, XML parser in Guile over an evening or two.) It is for > these reasons that I joined guile-devel not too long ago (after lurking on > guile-user for X years): I want to help keep Guile strong. > You may be interested in SSAX XML parser, which works on Guile. http://ssax.sf.net IMHO, Scheme is most effective XML-scripting language, and SSAX/SXML provide the proper infrastructure for this. Best regards, Kirill. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-22 18:36 ` Kirill Lisovsky @ 2002-04-23 7:53 ` rm 2002-04-23 15:11 ` Rob Browning 0 siblings, 1 reply; 21+ messages in thread From: rm @ 2002-04-23 7:53 UTC (permalink / raw) Cc: bitwize, Nicolas Neuss, Tanel Tammet, guile-devel On Mon, Apr 22, 2002 at 10:36:54PM +0400, Kirill Lisovsky wrote: > On Mon, 22 Apr 2002 bitwize@wizards-of-source.org wrote: > > > long time with another language. (I once wrote a fairly complete, albeit > > non-validating, XML parser in Guile over an evening or two.) It is for > > these reasons that I joined guile-devel not too long ago (after lurking on > > guile-user for X years): I want to help keep Guile strong. > > > You may be interested in SSAX XML parser, which works on Guile. > http://ssax.sf.net > > IMHO, Scheme is most effective XML-scripting language, and SSAX/SXML > provide the proper infrastructure for this. I agree with that, but remember, XML _needs_ unicode strings (no way arround that) and unfortunately guile doesn't have builtin unicode support. Pretty much a show stopper :-( Ralf > Best regards, > Kirill. > > > > _______________________________________________ > Guile-devel mailing list > Guile-devel@gnu.org > http://mail.gnu.org/mailman/listinfo/guile-devel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-23 7:53 ` rm @ 2002-04-23 15:11 ` Rob Browning 0 siblings, 0 replies; 21+ messages in thread From: Rob Browning @ 2002-04-23 15:11 UTC (permalink / raw) Cc: Kirill Lisovsky, bitwize, Nicolas Neuss, Tanel Tammet, guile-devel rm@fabula.de writes: > I agree with that, but remember, XML _needs_ unicode strings (no way > arround that) and unfortunately guile doesn't have builtin unicode > support. Pretty much a show stopper :-( This is one of the things I'd like to put on the post 1.6.1 agenda. I know it's been beaten to death more than once here, but last time it sounded like we almost came up with something we could all live with. I'd also like to discuss compilation, and versioning of scheme level modules via (use-modules (foo bar :interface 3)) or similar. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-17 12:21 Roadmap and goals? Tanel Tammet ` (2 preceding siblings ...) 2002-04-19 8:38 ` Nicolas Neuss @ 2002-04-20 7:47 ` Thien-Thi Nguyen 2002-05-14 8:26 ` Thien-Thi Nguyen 3 siblings, 1 reply; 21+ messages in thread From: Thien-Thi Nguyen @ 2002-04-20 7:47 UTC (permalink / raw) Cc: guile-devel From: Tanel Tammet <tammet@staff.ttu.ee> Date: Wed, 17 Apr 2002 15:21:47 +0300 I guess it would benefit not only me but the Guile development and acceptance on a wider scale if such guides, policies, roadmaps etc existed and were easy to locate. for some of this, see: http://www.glug.org/snap/workbook/ please consider critiquing everything under there (in particular what does "defining the execution model" mean) wrt compilation. this would be immediately helpful. (additions gladly accepted, no q's asked.) long-term direction is now in discussion. process awareness is seeded but not flourishing yet, so current communication rates cannot be used reliably to predict outcome. you are invited to start a bof discussion using subject-line prefix "[comp]". it was because of hobbit that i became interested in guile, so if hobbit long-term does not support guile, i would have serious doubts about staying w/ guile. on the other hand, i also view this as an opportunity to learn precisely what hobbit needs, so that perhaps long-term, people can make guile support hobbit through becoming more precise in what guile provides. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-20 7:47 ` Thien-Thi Nguyen @ 2002-05-14 8:26 ` Thien-Thi Nguyen 0 siblings, 0 replies; 21+ messages in thread From: Thien-Thi Nguyen @ 2002-05-14 8:26 UTC (permalink / raw) Cc: guile-devel From: Thien-Thi Nguyen <ttn@giblet.glug.org> Date: Sat, 20 Apr 2002 00:47:10 -0700 From: Tanel Tammet <tammet@staff.ttu.ee> Date: Wed, 17 Apr 2002 15:21:47 +0300 I guess it would benefit not only me but the Guile development and acceptance on a wider scale if such guides, policies, roadmaps etc existed and were easy to locate. for some of this, see: http://www.glug.org/snap/workbook/ for compilation specific notes, see: http://www.glug.org/snap/workbook/compilation/ it's still pretty sparse, but perhaps that will change. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? @ 2002-04-20 12:55 Kirill Lisovsky 2002-04-20 20:01 ` Rob Browning 0 siblings, 1 reply; 21+ messages in thread From: Kirill Lisovsky @ 2002-04-20 12:55 UTC (permalink / raw) Cc: guile-user Hello! Working for a long time with a half-dozen of different Schemes in IT and CS projects, I've some "comparative impression". Tanel Tammet wrote: > (*) what are the specific benefits of using Guile. > > For example, why exactly should somebody > use Guile instead of SCM or Bigloo: > what are the specific advantages and > what is the downside. Why not use just > SCM or Bigloo (they are faster, you know :-) > There have to be answers to this question, > just that I do not know the answers. > Bigloo has nice and fast compiler but its interpreter is slow and compiler-incompatible. It makes sense if the application has to be compiled rather than interpreted. Bigloo not quite Scheme in proper-tail recursion considerations, but it's fast and may be useful for practical purposes. Unix-oriented. It has a usable JVM backend also. SCM is a good Scheme, but it has no case sensitive reader, which is a big disadvantage for some applications (XML is most important example for me). IMHO, PLT is most advanced and most promising "big" Scheme. Version 200 is a great improvement, its design and principles are reasonable and clear. A lot of libraries, active development, multiple platforms, and so on ... I like Gambit a lot, but it's not free for commercial projects. Compiler to C. Extremely robust. Chicken is relatively young but already usable. It has a solid theoretical basis and good C interface. Compiler to C. Guile - it is the slowest one, I'm afraid :-) Well, it's better _interpreter_ than Bigloo ... IMHO, it's main advantage is large installation/users base. But a mess with versions: 1.7.x , 1.6.x, 1.5.x while latest Linux distros are using 1.4.x or even 1.3.4! (1.3.4 is used by RedHat 7.2 which makes a lot of installed Guiles pretty obsolete...) Using Guile since 1999 I'm still ignoring its latest additions due to this zoo of versions... As the result, I mostly use Guile to run Scheme scripts on "just OS installed" Linux/BSD boxes. If I'm to install some Scheme, then (usually) it is not Guile... So, this is my point of view: 1. Guile may have a good future as fast and compact "R5RS SIOD" with a lot of (optional !) libraries. 2. Unification of Scheme implementations will be highly desirable from the practical point of view. Co-existence of ten "major Schemes" is a major practical disadvantage. 3. PLT is best _full-blown_ Scheme implementation now. It's designed as core + libraries. Porting (best and absent in PLT) Guile's code as PLT collections is most realistic way to unification. Best regards, Kirill Lisovsky. http://pair.com/lisovsky/ P.S. Forward of Nicolas's message to guile-user@gnu.org is the reason of this posting. Please, don't consider it as destructive :-) > ------- Start of forwarded message ------- > From: Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> > Subject: Re: Roadmap and goals? > Date: 19 Apr 2002 10:38:06 +0200 ... > P.S.2: I thought about sending this also to guile-user@gnu.org. I > refrained from doing so, because Tamel did not do that, and because I > do not want to be too destructive. But IMHO, also users should know > about these problems in Guile's design. So, it remains for you > maintainers to inform them... _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Roadmap and goals? 2002-04-20 12:55 Kirill Lisovsky @ 2002-04-20 20:01 ` Rob Browning 0 siblings, 0 replies; 21+ messages in thread From: Rob Browning @ 2002-04-20 20:01 UTC (permalink / raw) Cc: guile-devel, guile-user Kirill Lisovsky <lisovsky@acm.org> writes: > Guile - it is the slowest one, I'm afraid :-) > Well, it's better _interpreter_ than Bigloo ... > IMHO, it's main advantage is large installation/users base. > But a mess with versions: 1.7.x , 1.6.x, 1.5.x while latest Linux distros > are using 1.4.x or even 1.3.4! > (1.3.4 is used by RedHat 7.2 which makes a lot of installed Guiles pretty > obsolete...) > Using Guile since 1999 I'm still ignoring its latest additions > due to this zoo of versions... After 1.3.4 it *should* be pretty clear -- the numbering scheme is the same as that of the linux kernel now, given MAJOR.MINOR.MICRO, releases with odd MINOR numbers are unstable, i.e. 1.5.* is an unstable beta release, and even numbers are stable. 1.6.1 will be the next stable release. Perhaps this isn't yet well enough known since it was only decided after 1.4 and so is only documented in CVS ATM. The problem with RedHat is a separate problem I think I understand pretty well, and that I'm planning to try and help fix soon. One issue in the FWIW category with respect to performance -- I've got a partially working set of benchmarks here that I can run via a "make". I'm planning to commit these tests to a CVS module (after I make sure the copyrights allow that) so we can use it for checking our work. Most of the benchmarks I have working right now are taken from stalin, and so I've had to tone their workload down by orders of magnitude so they'll actually run in a reasonable time with guile -- stalin is of course ridiculously faster in these tests. > P.S. Forward of Nicolas's message to guile-user@gnu.org > is the reason of this posting. Please, don't consider it as > destructive :-) Not at all, thanks for your comments. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2002-05-14 8:26 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-04-17 12:21 Roadmap and goals? Tanel Tammet 2002-04-17 20:59 ` Neil Jerram 2002-04-18 8:37 ` Panagiotis Vossos 2002-04-19 9:14 ` Panagiotis Vossos 2002-04-20 6:58 ` Thien-Thi Nguyen 2002-04-20 10:18 ` Panagiotis Vossos 2002-04-18 14:58 ` bitwize 2002-04-18 19:26 ` Rob Browning 2002-04-20 7:23 ` Thien-Thi Nguyen 2002-04-18 0:57 ` Christopher Cramer 2002-04-19 17:36 ` Marius Vollmer 2002-04-19 8:38 ` Nicolas Neuss 2002-04-21 15:14 ` Rob Browning 2002-04-21 22:26 ` bitwize 2002-04-22 18:36 ` Kirill Lisovsky 2002-04-23 7:53 ` rm 2002-04-23 15:11 ` Rob Browning 2002-04-20 7:47 ` Thien-Thi Nguyen 2002-05-14 8:26 ` Thien-Thi Nguyen -- strict thread matches above, loose matches on Subject: below -- 2002-04-20 12:55 Kirill Lisovsky 2002-04-20 20:01 ` Rob Browning
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).