emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Python vs Lisp (followups to -tangents)


From: Sam Steingold
Subject: Re: Python vs Lisp (followups to -tangents)
Date: Thu, 10 Dec 2015 13:40:39 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

> * Random832 <address@hidden> [2015-12-10 16:13:30 +0000]:
>
> On 2015-12-10, Richard Stallman <address@hidden> wrote:
>
>> I skimmed documentation of Python after people told me it was
>> fundamentally similar to Lisp. My conclusion is that that is
>> not so. `read', `eval', and `print' are all missing in Python.
>
> I must admit, I don't fully understand what you mean by this.
>
> Print is the most confusing. As a feature, Lisp's 'print' can be
> described as: Produce a string representation which can be read
> back of some objects (certainly not *all* objects - not buffers
> or subroutines, for example, and it's not structure-preserving
> for lists of lists), and display it on standard output.

This is false.
Nested lists are certainly printed readably:

--8<---------------cut here---------------start------------->8---
(defvar l '(1 (2 3) 4 (5 (6 (7 (8))))))
(equal l (read (prin1-to-string l)))
==> t
--8<---------------cut here---------------end--------------->8---


> Python's 'repr' could be regarded as an exact match in concept
> for prin1-to-string, a building block from which Lisp's 'print'
> can be trivially made. The essential feature - that there is a
> way to get a string that can be read back for objects for which
> it is reasonable/easy - is present.

True, but irrelevant.
An important feature is missing: repr is not defined for classes
automatically.

> Python's 'eval'/'exec' normally evaluates code directly from a
> string, skipping the need for 'read' entirely.

A string is too unstructured.

> However, if desired, the 'ast' module provides a rich framework for
> working with expression trees - the only difference is that they're
> built from class-based objects instead of just being a list of
> lists/symbols/literals.

These class-based objects cannot be printed readably (IIUC).

The point Richard is making is that Python lacks macros, i.e., you
cannot easily write code which writes code.
You have to either operate at the level of strings (which is hard to get
right) or at the level of AST (which is even harder).

Even more succinctly, in Lisp data and code are the same: lists of
lists, symbols, strings &c.
In Python, data is (mostly) strings and code is AST.


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://memri.org http://islamexposedonline.com
http://truepeace.org http://www.dhimmitude.org http://camera.org
Old Age Comes at a Bad Time.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]