From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.tangents Subject: Re: 2016-05-23 Emacs News Date: Fri, 10 Jun 2016 15:52:21 +0200 Message-ID: <87shwlf8x6.fsf@mbork.pl> References: <87lh30iv18.fsf@sachachua.com> <87bn39ewp6.fsf@linux-qg7d.fritz.box> <87twh1gwu8.fsf@members.fsf.org> <8737oldv21.fsf@linux-qg7d.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1465566786 3508 80.91.229.3 (10 Jun 2016 13:53:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 13:53:06 +0000 (UTC) Cc: emacs-tangents@gnu.org To: Rolf Ade Original-X-From: emacs-tangents-bounces+get-emacs-tangents=m.gmane.org@gnu.org Fri Jun 10 15:52:55 2016 Return-path: Envelope-to: get-emacs-tangents@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 1bBMrm-0001gh-NV for get-emacs-tangents@m.gmane.org; Fri, 10 Jun 2016 15:52:54 +0200 Original-Received: from localhost ([::1]:41242 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBMrm-0000tl-0P for get-emacs-tangents@m.gmane.org; Fri, 10 Jun 2016 09:52:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBMrR-0000qF-ON for emacs-tangents@gnu.org; Fri, 10 Jun 2016 09:52:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBMrL-0005Wl-Sh for emacs-tangents@gnu.org; Fri, 10 Jun 2016 09:52:32 -0400 Original-Received: from mail.mojserwer.eu ([195.110.48.8]:43621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBMrL-0005Un-Kk for emacs-tangents@gnu.org; Fri, 10 Jun 2016 09:52:27 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 945C4BFCD4D; Fri, 10 Jun 2016 15:52:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB4PIAssSKv1; Fri, 10 Jun 2016 15:52:19 +0200 (CEST) Original-Received: from localhost (ehc19.neoplus.adsl.tpnet.pl [83.21.92.19]) by mail.mojserwer.eu (Postfix) with ESMTPSA id C069DBFCD4A; Fri, 10 Jun 2016 15:52:19 +0200 (CEST) User-agent: mu4e 0.9.16; emacs 25.1.50.3 In-reply-to: <8737oldv21.fsf@linux-qg7d.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 195.110.48.8 X-BeenThere: emacs-tangents@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-tangents-bounces+get-emacs-tangents=m.gmane.org@gnu.org Original-Sender: "Emacs-tangents" Xref: news.gmane.org gmane.emacs.tangents:132 Archived-At: On 2016-06-10, at 15:37, Rolf Ade wrote: > Nicolas Richard writes: >> Rolf Ade writes: >>> (That is: >>> http://mbork.pl/2016-05-23_Literal_values_and_destructive_functions) >>>=20 >>> Wait, what? >>> [...] >>> in *Messages*. Could someone please explain that to me? >> >> The article you're referring to explains just that. Is it somehow >> unclear ? Quoting the article: >> >> | What=E2=80=99s going on? >> |=20 >> | Well, the literal in the function definition was actually changed. (= If >> | you evaluate the defun form now, it will be redefined once again to >> | the =E2=80=9Ccorrect=E2=80=9D value.) If you don=E2=80=99t believe i= t, try this: M-: >> | (symbol-function #'destructive-havoc), or even better, M-x >> | pp-eval-expression RET (symbol-function #'destructive-havoc) RET and >> | see for yourself. > > Well ..., sorry, yes, that explanation isn't clear to me. While I'm > far away to claim I'm a versed emacs lisp programmer, I've written a fe= w > screen full of emacs lisp code. Now this thing left me back with the > feeling, that I've missed to understand something at the core of the > language (with the additional unpleasant feeling, that my emacs lisp > programming is even more cargo cult coding, than I already suspected). > > The "explanation", that the literal in the function definition was > changed by the (sort) call doesn't help me on track. While I'm fluent > with other programming languages, that are able to rewrite function > definitions during run-time I don't know a programming language that do > this as a 'side effect' of a function call (other than you craft one, > that deliberate does so). > > Is what the article demonstrates something special to the 'build-in' > function sort or to emacs lisp? It would help me, if someone explains > what happen in this example in other words (not in implementation detai= l > but language concepts). Hi, original author here. Sorry for being rather terse. I've got only a couple of minutes, but let me try. It's not like `sort' changes the _function_. But the function contains a _literal structure_ (like "a constant"), and it is remembered as a "pointer" (conceptually, not necessarily in C sense). So when `sort' changes the structure "pointed to" by its argument (and it gets the "pointer" to the very same structure referred to by the function), it looks like the function is changed. Is that better? (If yes, I'll amend the article.) BTW, AFAIK, other Lisps have it similar with destructive functions. Best, --=20 Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University