Re: Python vs Lisp (followups to -tangents)

[Random832 <random832@fastmail.com>]

On 2015-12-10, Sam Steingold <sds@gnu.org> wrote:
> This is false.
> Nested lists are certainly printed readably:

What I meant by "not structure-preserving" is that the output is
the same, ((1 2) (1 2)), for these lists:

(let  ((x '((1 2) (1 2))))         (eq (car x) (cadr x))) ==> nil
(let* ((a '(1 2)) (x `(,a ,a)))    (eq (car x) (cadr x))) ==> t
(let  ((x (read "((1 2) (1 2))"))) (eq (car x) (cadr x))) ==> nil

(Or for that matter, let*
 ((b '(2)) (x (list (cons 1 b) (cons 1 b))))...)

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

Sure it is. It's just defined to the same kind of useless value
that Lisp has for buffers and subroutines.

>> 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).

It's unfortunate that this is not their repr output, but the
ast.dump function provides this:

>>> ast.dump(ast.parse("1 + 1"))
'Module(body=[Expr(value=BinOp(left=Num(n=1), op=Add(), right=Num(n=1)))])'
>>> eval(ast.dump(ast.parse("1 + 1")), ast.__dict__)
<_ast.Module object at 0x7fcd79b24908>

> 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).

I don't see how operating at the level of AST is harder than
operating at the level of lists (backquote operates above the
level of lists; it automatically searches the code you give it
for placeholders to substitute values in. It probably wouldn't
be hard to write an equivalent in Python.)

> 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.

I guess I don't see how being a little rough around the edges or
not working exactly the same way is the same thing as missing
the essential features entirely.

And this really isn't a valid objection to the claim being
discussed, which is that Python is similar to a hypothetical
M-expression lisp.