From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Guile in Emacs (was: integer overflow) Date: Mon, 12 Apr 2010 13:05:39 -0700 Message-ID: <1271102739.6067.38.camel@dell-desktop.example.com> References: <4B8147A9.7030504@gmail.com> <87ljemdzxo.fsf@stupidchicken.com> <4B83682D.5010804@gnu.org> <87vddmpw4s.fsf@stupidchicken.com> <87hbp2fwoi.fsf@gnu.org> <87wrxrr4md.fsf@gnu.org> <3vsk8ecg6a.fsf@fencepost.gnu.org> <873a0euot4.fsf@stupidchicken.com> <873a0cyv3r.fsf@lola.goethe.zz> <87aauiho3y.fsf_-_@lifelogs.com> <1271028837.6164.55.camel@dell-desktop.example.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1271102859 2464 80.91.229.12 (12 Apr 2010 20:07:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Apr 2010 20:07:39 +0000 (UTC) Cc: tzz@lifelogs.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 12 22:07:37 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O1Pux-00043I-2e for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 22:07:35 +0200 Original-Received: from localhost ([127.0.0.1]:36207 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1PuP-0003Rq-VY for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 16:07:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1PtC-0002uk-0T for emacs-devel@gnu.org; Mon, 12 Apr 2010 16:05:46 -0400 Original-Received: from [140.186.70.92] (port=52836 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1Pt9-0002tp-At for emacs-devel@gnu.org; Mon, 12 Apr 2010 16:05:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1Pt6-0007EM-OJ for emacs-devel@gnu.org; Mon, 12 Apr 2010 16:05:43 -0400 Original-Received: from smtp141.iad.emailsrvr.com ([207.97.245.141]:51777) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1Pt6-0007EE-L1 for emacs-devel@gnu.org; Mon, 12 Apr 2010 16:05:40 -0400 Original-Received: from relay24.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 594E11B4009; Mon, 12 Apr 2010 16:05:40 -0400 (EDT) Original-Received: by relay24.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 942A01B4EBF; Mon, 12 Apr 2010 16:05:39 -0400 (EDT) In-Reply-To: X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123539 Archived-At: On Mon, 2010-04-12 at 08:30 -0400, Richard Stallman wrote: > When I read about Sun's plan to make TCL the universal scripting > language, I decided to oppose that. The plan I chose was to implement > Scheme and support other scripting languages by translation into Scheme. > Guile is the program I chose to adopt to do this with. That plan > is what I am talking about. > > Whatever history that code had before its adoption for this plan > is not what I am talking about. Sure. In one sense it was just your use of the word "original" as in "original goal" that I was objecting too. Yet, there is another aspect of this which I think is relevant to "Guile in Emacs" and to your notion of supporting other scripting languages -- otherwise I wouldn't harp on it: In those early days of Guile, after your decision, those of us closer to the project discussed at considerable length how exactly to support Tcl, Emacs lisp, and other languages. Not just how to be able to run programs in those languages but how to integrate them into a cohesive environment. In each and every case we discovered devils in the details and realized "Well, we can't." We could make a TCL-like language that could run many simple TCL programs but that would not be upward compatible - and have that TCL-like language nicely integrated with the larger environment. We could make an Emacs Lisp style of environment that could run some Emacs Lisp code directly but that would not be upwards compatible - and have that alternative Emacs Lisp nicely integrated with the larger environment. But we absolutely could not, for fundamental reasons, directly support Tcl and Emacs Lisp with fidelity and wind up with a sane programming environment. We realized that pretty quickly and tried (but failed) to convey to you this notion that we could not promise to seamlessly integrate those other languages - but that we could offer a reasonable compromise. It was always an oversimplifying exaggeration to say that Guile would support all of those other languages in any strong sense of the word "support". We could offer alternative syntaxes. We could offer environments with simplified evaluation models and more flexible types. We could give people the *feel* of Tcl or Python or Emacs Lisp but there was no point in trying to faithfully reimplement those languages in detail. We failed miserably at communicating that distinction, apparently. There was some momentary political convenience, back then, around the burning question of which scripting language would "win" and take over the world. Would Tcl become the ubiquitous scripting language? Python? It was an easy story to tell that Guile somehow transcended the question for it could be both Tcl *and* Python (*and* Scheme) depending solely on user preference. But it was clear at the technical level that really Guile could only be Scheme, pure and simple, although perhaps offering a Tcl-*like* environment and a Python-*like* environment. We - meaning you, me, and several others - were sloppy back then about making that distinction clear. If anything remains of the shared *technical* vision of a complete GNU system that is lisp-centric with many extensible, self-documenting programs -- and if sentiment remains that Scheme is a fine choice for extension language -- then I mainly hope that people pursuing that vision today won't go down the same rat-hole that caught us up back then. "I, alone, survive to tell the tale...". If you want a half-decent Scheme as your core extension language then *make that work first* and don't worry so much about compatibility with legacy code in those other languages. There are no good answers about how to cleanly integrate Emacs Lisp and other languages with Scheme at that level. People have thought about for, what, something over 15 years now and the ones thinking about it today are getting stuck going over the very same questions people got stuck on 15 years ago. Meanwhile, with all the (often interesting and skilled - admirable) work that has gone down that rat-hole in those years, a thoroughly Scheme-based but not upwards compatible Emacs could have been casually produced by, say, 10 or 12 years ago. Coulda' Shoulda' Woulda' but Didn't, as the saying goes. I just hope that the next 10 years of GNU generally and Emacs specifically isn't going to be tied down to the historic baggage of the "Tcl Wars" and the misunderstandings it provoked. Someone -- that is to say "someone" -- should just rip Emacs Lisp out of the C part of GNU Emacs, bind the best parts of that stuff to Guile, and start *there*. It's not a small job but it's also not a "more than a decade" job. It could have been started much more than a decade ago. It'd be, in my view, a giant leap back towards the vision of a GNU system that was shared among several key GNU hackers back in the early 1990s and earlier. And it'd be, in my view, technically sane in comparison to some more popular alternatives like trying to support Emacs Lisp in detail. I'm done. I've said my piece. -t