From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: ELisp - Making a list from a function returning a number Date: Fri, 18 Dec 2020 20:53:23 +0300 Message-ID: References: <87ft4318fj.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23192"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 18 18:56:27 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kqJzP-0005wE-Ji for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 18 Dec 2020 18:56:27 +0100 Original-Received: from localhost ([::1]:56472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kqJzO-0001pq-L7 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 18 Dec 2020 12:56:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42910) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqJz1-0001pe-Pr for help-gnu-emacs@gnu.org; Fri, 18 Dec 2020 12:56:03 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:60041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqJyy-0007r4-Vs for help-gnu-emacs@gnu.org; Fri, 18 Dec 2020 12:56:03 -0500 Original-Received: from localhost ([::ffff:41.202.241.37]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E537.000000005FDCED2D.00002A3B; Fri, 18 Dec 2020 10:55:57 -0700 Content-Disposition: inline In-Reply-To: <87ft4318fj.fsf@zoho.eu> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:126515 Archived-At: * Emanuel Berg via Users list for the GNU Emacs text editor [2020-12-18 17:45]: > steve-humphreys wrote: > > > This is my new function > > > > (defun timgrid () > > > > (let* ( (tstr 800) > > (tend 1300) > > (tpd 34) > > (i 0) > > (tim tstr) > > tim tfr ) > > ;; ----- body of let ----- > > (dotimes (i 4) > > (message "tim tpd: %d %d" tim tpd) > > (setq tfr (timfutur tim tpd)) > > (message "tim: %d" tim) > > ;;(setq tlist (append 'tlist (list tim))) > > (setq tim tfr)) )) > > Please, > > 1. use more understandable language. this is Lisp, not > assembly language... No, quite contrary. LISP allows for any paradigm of programming. Linear programming, etc. It does not matter. I see no problem there like you see it. Many of my command line tools in Common Lisp only load other programs and invoke one let. There are conventions, but first LISP programs was not written in any of our today's conventions. I would say that LISP convention is good that variables may be described easier. Instead of `tstr' one could say `time-start' or instead `tend' one could freely say `time-end'. Then again I will sometimes use just a, b, c for variables. > 2. remove blank lines and commented out lines For one's own understanding this may help. Step by step. Learning goes on gradient. > 3. don't use comments that do not add any information (e.g., > "body of let" - but that is already plain and true, by > definition) That is what you know on a different gradient. Even more comments would be required on beginning gradient and this in all programming languages. Advanced programmers need no comments, they read the code. I have little difficulties reading scheme code due to little bit more functional way of programming, but reading Emacs functions is often terrible for me due to way how they are written. > 4. use the normal indentation space for Elisp, in `elisp-mode' two > spaces It may be hard to understand for new Elisp programmer what you mean here. I do not use nothing, I use elisp-mode and I press TAB or M-q to indent everything in a region. I would not even know how it should be indented if I would not be using emacs lisp mode. > 5. again, don't use `setq' in function bodies when there is no > need, you already have the vars in let*, do all computation > there (add more vars if necessary, for clarity, even) Especially in a list within `let' form there is no problem in using `setq'. In that above example I can fully understand that way of doing things as it gives clearer picture on what is happening. First comes inception then shape.