From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Huchler Newsgroups: gmane.emacs.help Subject: Re: Strange eval behaviour Date: Tue, 22 Nov 2016 15:43:24 +0100 Message-ID: <87eg23y3qr.fsf@mail.de> References: <87vavrul0k.fsf@mail.de> <878tsl1p7b.fsf@mail.de> <878tshjyvy.fsf@web.de> <87fumo67vi.fsf@mail.de> <87h974l5u2.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1479830646 8500 195.159.176.226 (22 Nov 2016 16:04:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 22 Nov 2016 16:04:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 22 17:04:00 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c9DY8-0000w9-Fg for geh-help-gnu-emacs@m.gmane.org; Tue, 22 Nov 2016 17:04:00 +0100 Original-Received: from localhost ([::1]:56353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9DYA-0001VD-EF for geh-help-gnu-emacs@m.gmane.org; Tue, 22 Nov 2016 11:04:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9CIM-0003Ye-Jk for help-gnu-emacs@gnu.org; Tue, 22 Nov 2016 09:43:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9CIH-0004N3-MR for help-gnu-emacs@gnu.org; Tue, 22 Nov 2016 09:43:38 -0500 Original-Received: from [195.159.176.226] (port=33265 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c9CIH-0004Li-G5 for help-gnu-emacs@gnu.org; Tue, 22 Nov 2016 09:43:33 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1c9CIA-0002im-Sk for help-gnu-emacs@gnu.org; Tue, 22 Nov 2016 15:43:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 72 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:smsIXhd98Zt2OgBB4318g25STr4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-Mailman-Approved-At: Tue, 22 Nov 2016 11:03:30 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:111761 Archived-At: Michael Heerdegen writes: > Stefan Huchler writes: > >> Or did you refer here to something different you saw? bytecompiling >> only throw warnings about this params variables. And thats only >> warnings... > > But the warnings are there for a reason, and the reason is that the code > can potentially error when being run. In general, the warnings mean > that you do something you definitely should not do. Let's fix these > warnings, and then I can have a look at the code again if you want. Yes but when I know (or belive strongly) that I have nothing that causes problems I fix warnings as last thing, not as first (at least normaly) and I am pretty shure that this setq does not create problems, only if somethnig else also uses global variables with the name params :). So basicly if I AND somebody else messed up, then it creates problems. And yes I work best practises in my lisp workflow coding style in one by one. > Also try to follow the essence of functional programming: reduce side > effects of functions to a minimum. When a function has side effects, > make it clear (e.g. in the doc or the name of the function). I dont write a doc for a code I will replace before I release it anyway :) > If you > really need to set any global variable, declare that variable with > `defvar' and prefix its name with the prefix of your library. In > general, the way functions transfer information in Lisp is by the return > value, not by setting variables. For avoiding some bad habits it's very > helpful to use lexical-binding - you can enable it with a specification > in the file's first line. Yeah I know that this is no good idea especialy if you upload it, cause the main problem is not if you do it in one local package but if everybody would do that, you have many times incompatible packages basicly. I know about that, I just used it because I concentrated primary on the json code and to get something working, and at the time it was just easier and faster to do it that way. Also I dont want to refactor stuff while stuff is not working, I wanted to get to a working state first. And I was not aware of the bytecompiling and that macros dont get "live" evaluated basicly I am used to code that when its wrong gives me some sort of error. > Maybe consider reading a good book about lisp (since learning by doing > is not a good approach in Lisp). Maybe "Land of Lisp" (haven't read it, > but it has a good title song) or "On Lisp" by Graham (a classical, but > harder to read; reading some of the first chapters might be a good idea > anyway). I am not so good at reading books, I need a reason to do things other than learn somethnig abstract :) I do that for fun, startet with a send-youtube-to-kody thing and got then bigger and bigger. Of course if I run more often into such things, I consider reading a few pages of a book. I just learned no language by book, not Java, not c++, not python, not php... But I think you CAN learn everything online or with the offline documentiation, books tend just to focus a bit narrower on the juice stuff, but therefor you have to go through some stupid example code I dont care and cant relate to. Whatever still I might consider it in the future. The main problem was that I did not even have the idea to try to bytecompile it, so I did not even see that warnings ever.