From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sam Steingold Newsgroups: gmane.emacs.devel,gmane.emacs.tangents Subject: Re: Python vs Lisp (followups to -tangents) Date: Wed, 16 Dec 2015 10:57:45 -0500 Organization: disorganization Message-ID: <86vb7ytmh2.fsf@gnu.org> 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> Reply-To: sds@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1450281587 7429 80.91.229.3 (16 Dec 2015 15:59:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Dec 2015 15:59:47 +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 Wed Dec 16 16:59:34 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 1a9EUG-0002FF-PP for ged-emacs-devel@m.gmane.org; Wed, 16 Dec 2015 16:59:32 +0100 Original-Received: from localhost ([::1]:48025 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9EUG-0000Pv-B1 for ged-emacs-devel@m.gmane.org; Wed, 16 Dec 2015 10:59:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9ET4-0007ck-2Y for emacs-devel@gnu.org; Wed, 16 Dec 2015 10:58:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9ET1-0000Lq-70 for emacs-devel@gnu.org; Wed, 16 Dec 2015 10:58:18 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:37862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9ET1-0000Lh-0b for emacs-devel@gnu.org; Wed, 16 Dec 2015 10:58:15 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1a9ESw-0008VD-2w for emacs-devel@gnu.org; Wed, 16 Dec 2015 16:58:10 +0100 Original-Received: from 69.74.59.115 ([69.74.59.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Dec 2015 16:58:10 +0100 Original-Received: from sds by 69.74.59.115 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Dec 2015 16:58:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Followup-To: gmane.emacs.devel Original-Lines: 90 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69.74.59.115 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-Attribution: Sam X-Disclaimer: You should not expect anyone to agree with me. Cancel-Lock: sha1:0cJXp61QHK8Qv2111aDh44YxxEM= 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:196382 gmane.emacs.tangents:48 Archived-At: > * Random832 [2015-12-10 22:31:49 +0000]: > > 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))))...) please examine the `print-circle' variable. >> 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. The #<...> format is reserved for objects which cannot be meaningfully read back. Still, it contains plenty of information for a human. Python prints junk when it could have been printing machine-readable info. >>> 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> yep, with some additional cruft Python can almost do something that Lisp does for free. >> 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.) I am afraid you do not quite understand what you are talking about. >> 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. You have seen a car but never rode or driven one and you are trying to convince me that your tricycle is better. Seriously, this is the wrong forum for this discussion. I suggest that you learn more about Lisp (see, e.g., Paul Graham's "On Lisp", or http://letoverlambda.com/). -- Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000 http://www.childpsy.net/ http://think-israel.org http://americancensorship.org http://openvotingconsortium.org http://memri.org http://mideasttruth.com "A pint of sweat will save a gallon of blood." -- George S. Patton