Re: ELisp - Making a list from a function returning a number

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor 
<help-gnu-emacs@gnu.org> [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.