From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Random832 Newsgroups: gmane.emacs.devel,gmane.emacs.tangents Subject: Re: Python vs Lisp (followups to -tangents) Date: Thu, 10 Dec 2015 22:31:49 +0000 (UTC) Message-ID: References: <87io4lem98.fsf@petton.fr> <56604A9C.7080508@gmail.com> <20151208130529.GA28682@HAL9000> <1c367763-4ba1-4c65-80d1-be1b365c3b35@default> <87lh94hde0.fsf@mbork.pl> <86oadyjgew.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449786750 29834 80.91.229.3 (10 Dec 2015 22:32:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2015 22:32:30 +0000 (UTC) Cc: emacs-tangents@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 10 23:32:21 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a79l5-0004kh-I7 for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2015 23:32:19 +0100 Original-Received: from localhost ([::1]:44727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a79l4-0005xO-Vz for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2015 17:32:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a79l1-0005wc-Kw for emacs-devel@gnu.org; Thu, 10 Dec 2015 17:32:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a79ky-0005FV-EB for emacs-devel@gnu.org; Thu, 10 Dec 2015 17:32:15 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:35764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a79ky-0005FP-8A for emacs-devel@gnu.org; Thu, 10 Dec 2015 17:32:12 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1a79kk-0004CI-EU for emacs-devel@gnu.org; Thu, 10 Dec 2015 23:31:58 +0100 Original-Received: from c-68-39-146-59.hsd1.in.comcast.net ([68.39.146.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Dec 2015 23:31:58 +0100 Original-Received: from random832 by c-68-39-146-59.hsd1.in.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Dec 2015 23:31:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Followup-To: gmane.emacs.tangents Original-Lines: 63 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-68-39-146-59.hsd1.in.comcast.net User-Agent: slrn/pre1.0.3-7 (Linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196079 gmane.emacs.tangents:46 Archived-At: On 2015-12-10, Sam Steingold 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.