What did Stallman mean in this quote about implementing other languages in Lisp?

Question

I just read the following quote from Stallman as part of a speech he gave many years ago. He's talking about how it is feasible to implement other programming languages in Lisp, but not feasible to implement Lisp in those other programming languages.

He seems to take for granted that the listeners/readers understand why. But I don't see why. I think the answer will explain something about Lisp to me, and I'd like to understand it.

Can someone explain it?

Here's the quote:

"There's an interesting benefit you can get from using such a powerful language as a version of Lisp as your primary extensibility language. You can implement other languages by translating them into your primary language. If your primary language is TCL, you can't very easily implement Lisp by translating it into TCL. But if your primary language is Lisp, it's not that hard to implement other things by translating them."

The full speech is here: http://www.gnu.org/gnu/rms-lisp.html

Thanks.

Answer 1

You should read Paul Graham's Beating the Averages article, which explains why Lisp can implement other languages' concepts but usually not the other way around.

One of the key features Lisp has is real macros (as opposed to cpp or m4 macros). With macros, you can bend the language to whatever shape you'd like it to have. You can implement a complete OO system using Lisp macros, for example.

There are other benefits too, listed by other posters. But to me, macros is the main defining feature of Lisp.

Answer 2

There's a lot of good information in the other answers, but IMHO they are missing Stallman's point.

I believe Stallman was referring to the fact that Lisp itself is a nice regular abstract syntax tree which can be executed by a lisp interpreter or compiler. The process of interpreting or compiling TCL (or another non-lisp language) is one of converting the language's special and irregular syntax into an AST that can be executed. That AST can trivially be represented in valid Lisp sexps, which can then be made to run.

In contrast, converting Lisp to code in a language such as TCL requires converting Lisp's regular syntax into the target language's special constructs, carefully taking into account its quirks such as operator precedence, scoping and modularization.

This, I feel, is the point Stallman was making, independently of any specific language features particular Lisps may have.

Answer 3

He means that you're unlikely to encounter features you may want to implement that are not present in Lisp itself, so you can just "translate" them and use the underlying Lisp implementation, rather than having to implement them from scratch (which may be extremely hard depending on the language).

For example, TCL doesn't have closures (I believe), so if you were trying to implement a language that does, you'd have a pretty hard time of it in TCL, whereas in Lisp you would just use Lisp closures.

Or at least that's how I understand his argument.

Answer 4

He probably meant that it is relatively simple to implement any other language on top of Lisp, using its metaprogramming capabilities.

It is possible to do similar things with some other meta-languages, including Forth, but so far Lisp is the most advanced in this area.

One can implement C on top of Lisp, as a combination of a reader macro and a set of macros, transforming C semantics into an underlyin Lisp. But it is nearly impossible to natively implement Lisp on top of C, as a transparent layer.

For an impressive example of this technique I'd recomment to refer to Racket and its collection of languages built on top of its core Scheme.

Answer 5

I'm going to guess it is due to some features of LISP that are missing from other languages, and as a result would be difficult to implement effectively:

• higher order functions are (again, butchering it..) functions that operate on other functions. C's function pointers are neat, but functional languages combine functions frequently to get work done in an elegant manner.

• treating code as data (Link is to a specific page on a Google Books result, here's hoping it is portable.) Generating code from data is a fairly clever way to better manage complex coding operations. Most languages provide pretty poor tools for this: C's pre-processor isn't known for being easy or powerful, and I just can't read C++ template error messages. But LISP lets programmers treat their own programs as data, manipulate it, and then execute the result. The beauty is you've got the full power of the programming language to do it, not some hacky language tacked on when it became clear some kind of 'macro' facility would be useful.

Obviously, none of these are serious barriers to building language interpreters / parsers / virtual machines out of C, because we have Clojure running on a JVM written in C, continuations are familiar (and even humdrum) to legion Ruby and Python programmers (both implemented primarily in C), and Ruby's meta-programming ability is pretty reasonable. GCC and LLVM perform some tail-call analysis when compiling non-functional code. And so on.

I never really got the hang of LISP, so perhaps I'm missing the point completely.

Answer 6

As he writes in that article there was discussion about extension languages at that time and many people promoted TCL, while Stallman was coming from the Lisp camp. Stallman had worked with various forms of Lisp and developed Emacs Lisp as an extension language for the GNU Emacs editor. He also supported Guile as a general extension language for the GNU project.

TCL was popular at that time (also in combination with Tk) and was promoted for example by SUN.

One argument against TCL was that TCL itself was a very inefficient and relatively weak language. It was seen by Stallman mostly only for glue code - code which glues functionality together. For anything more interesting, one would need to implement the functionality in C (or similar) and use it from TCL.

Stallman thought that the part of software that could be implemented in Lisp in larger. See for example GNU Emacs. In GNU Emacs there is a C kernel which implements Emacs Lisp and some core functionality of the editor. But much of the rest of the code is written in Lisp itself.

It can be expected that an Emacs with TCL would have looked different and much more functionality would have been implemented on the C side. TCL also would be used as a very simple extension language. TCL as a language is simple and kind of 'string based'.

Answer 7

It's just that Lisp is, according to RMS (who would doubt his honesty on this subject?!), the most versatile language.

If you want some more in depth knowledge and arguments, you can check the famous (?) song : eternal flame

Answer 8

You can write a Lisp macro program to read another language and transform it into into the corresponding Lisp code, which then (obviously) is a regular piece of Lisp that can be used.

Answer 9

I think he means lot's of languages are Lisp-like, so if you know Lisp, it's easy to learn or use other languages. If you know TCL as your primary language, it's a lot harder to learn or use other languages.

In speaking, if you know Spanish as your primary language, then Italian and French are easier to understand and pick up because they have similar roots and use a lot of the same syntax and grammar. If Swahili is your primary language, then it's a lot harder to pick up other languages because there aren't a lot of other languages that are similar.