X-Received: by 10.66.65.202 with SMTP id z10mr1116341pas.45.1399817531696; Sun, 11 May 2014 07:12:11 -0700 (PDT) X-Received: by 10.50.143.71 with SMTP id sc7mr356970igb.4.1399817531585; Sun, 11 May 2014 07:12:11 -0700 (PDT) Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!r10no3073009igi.0!news-out.google.com!gi6ni804igc.0!nntp.google.com!c1no4599157igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.python Date: Sun, 11 May 2014 07:12:11 -0700 (PDT) In-Reply-To: <536f723c$0$29980$c3e8da3$5496439d@news.astraweb.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=59.95.16.32; posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui NNTP-Posting-Host: 59.95.16.32 References: <235C4BFA-9770-481A-9FCF-21C3F036769C@gmail.com> <87ppjpwafk.fsf@elektro.pacujo.net> <536ad8f2$0$29965$c3e8da3$5496439d@news.astraweb.com> <87zjiqbmy5.fsf@elektro.pacujo.net> <9cc0ebf9-dbed-4d3d-91fc-2abb9b0103d0@googlegroups.com> <536dc3f7$0$29980$c3e8da3$5496439d@news.astraweb.com> <536decca$0$29980$c3e8da3$5496439d@news.astraweb.com> <536E799D.6080602@stoneleaf.us> <536eebc1$0$29980$c3e8da3$5496439d@news.astraweb.com> <536f069b$0$29980$c3e8da3$5496439d@news.astraweb.com> <3fb2d95e-2fb6-43a5-a725-c6d38444b80c@googlegroups.com> <87ppjksum0.fsf@elektro.pacujo.net> <536f723c$0$29980$c3e8da3$5496439d@news.astraweb.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <35eb82b8-ca79-438e-bdde-430c6ffbfa3c@googlegroups.com> Subject: Re: Values and objects From: Rustom Mody Injection-Date: Sun, 11 May 2014 14:12:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: csiph.com comp.lang.python:71317 On Sunday, May 11, 2014 6:21:08 PM UTC+5:30, Steven D'Aprano wrote: > The point is, it is *logically impossible* for a language to use > precisely the same syntax for value-assignment and variable-assignment. > Consider the variable called "x", which is bound to the value 23. If the > language has a single assignment operator or statement: Its called set in classic lisp. Here's an emacs lisp session (the oldest lisp I can lay my hands on) The semicolons are comments like python's # *** Welcome to IELM *** Type (describe-mode) for help. ELISP> (set (quote d) "Hello World") "Hello World" ELISP> (set (quote c) (quote d)) d ELISP> ; those quote-s are getting boring ELISP> (set 'b 'c) c ELISP> ; once more short-form a very common case ELISP> (setq a 'b) b ELISP> ; Now unfold the chain ELISP> ; Level 0 ELISP> 'a a ELISP> ; Level 1 ELISP> a b ELISP> ;Level 2 ELISP> (eval a) c ELISP> ;Level 3 ELISP> (eval (eval a)) d ELISP> ;Level 4 ELISP> (eval (eval (eval a))) "Hello World" ELISP> IOW set UNIFORMLY evaluates its 2 arguments. To get usual assignment like behavior of normal programming languages, one (typically) quotes the first argument. This is a sufficiently common case that it gets its own 'special form' -- setq (ie set-quote) However the more general case in which (the name of)* the variable is evaluated at run-time is always available. * "Name of" is strictly not correct because: ELISP> (symbol-name 'a) "a" However if I dont say the "name of..." its hard to speak in an intelligible way. Here is the relevant intro from the elisp manual: A "symbol" in GNU Emacs Lisp is an object with a name. The symbol name serves as the printed representation of the symbol. In ordinary Lisp use, ... a symbol's name is unique--no two symbols have the same name. A symbol can serve as a variable, as a function name, or to hold a property list. Or it may serve only to be distinct from all other Lisp objects, so that its presence in a data structure may be recognized reliably. tl;dr: Quote-Eval go up and down the 'meta-language' tower just as Lambda-(function)Apply go up and down the functional tower. Elaborated further: http://blog.languager.org/2013/08/applying-si-on-sicp.html