[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile in Emacs (was: integer overflow)
From: |
Thomas Lord |
Subject: |
Re: Guile in Emacs (was: integer overflow) |
Date: |
Mon, 12 Apr 2010 13:05:39 -0700 |
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
- Re: Guile in Emacs (was: integer overflow), Thomas Lord, 2010/04/11
- Re: Guile in Emacs (was: integer overflow), Richard Stallman, 2010/04/12
- Re: Guile in Emacs (was: integer overflow),
Thomas Lord <=
- Re: Guile in Emacs, Bruce Stephens, 2010/04/13
- Re: Guile in Emacs, Thomas Lord, 2010/04/13
- Re: Guile in Emacs, Stefan Monnier, 2010/04/13
- Re: Guile in Emacs, Thomas Lord, 2010/04/13
- Re: Guile in Emacs, Christian Lynbech, 2010/04/13
- Re: Guile in Emacs, Bruce Stephens, 2010/04/14
- Re: Guile in Emacs, joakim, 2010/04/14
- Re: Guile in Emacs, Christian Lynbech, 2010/04/13
- Re: Guile in Emacs, Thomas Lord, 2010/04/13
- Re: Guile in Emacs, Christian Lynbech, 2010/04/13