lexical binding?

lexical binding?

[Jean-Christophe Helary]

I need to make sure I understand this properly.

When I "setq" variables in a defun, they are by default global, so, in the following code:

(defun checkDayTracker ()
  "Creates values for the new index, based on yesterday's values."
  (save-current-buffer
    (set-buffer (find-file-noselect dayTrackerPath))
    (goto-char (point-min))
    (search-forward-regexp "\\([0-9]*\\.[0-9]*\\) \\([0-9]*\\) \\([0-9]*\\) \\([0-9]*\\)")
    (setq timeStamp (match-string 1)
	  seasonNumber (match-string 2)
	  totalDays (+ 1 (string-to-number (match-string 3)))
	  dayInSeason (+ 1 (string-to-number (match-string 4)))
	  newTracker (format "%s %s %s %s\n" (float-time) seasonNumber totalDays dayInSeason))
    (goto-char (point-min))
	(insert newTracker)
	(save-buffer)
	(kill-buffer))
  (list seasonNumber totalDays dayInSeason)))	

I don't *need* to return a list with the values to expose them to other functions. I can just call the various variables by name directly in another defun.

If I wanted to have them strictly local, I'd use "let" and I would only be able to access them in the "let" block.

If the above is correct, is there anything else there is to know about lexical binding?
(I certainly do not presume that I've understood more than a very tiny portion of the surface of this issue so I suppose that the answer is yes, but...)

Also, in a 2018 thread that I started in December 2018, when I asked about using setq to create lists based on other lists, Robert Thorpe says "I've seen lots of beginners write programs that setq undefined symbols and now I know why." (https://lists.gnu.org/archive/html/help-gnu-emacs/2018-12/msg00025.html). What is the issue with using setq on undefined symbols? Can that break things eventually? Is that related to lexical binding?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: lexical binding?

[Stefan Monnier]

> When I "setq" variables in a defun, they are by default global,

The "in a defun" has no impact on the behavior: `setq` doesn't know
it's used from within a function.

> I don't *need* to return a list with the values to expose them to
> other functions. I can just call the various variables by name
> directly in another defun.

Not sure what you mean by "call" (which is a term usually used when you
use a function), but yes you can refer to the value of those variable by
name directly.

And if you do so, any seasoned programmer will look at your code and weep.

If you want  variable to be global, then always say it explicitly by
declaring it first with `defvar` and don't forget to use a name with
a proper namespace prefix so it doesn't collide with other
packages's variables.

Also, remember to byte-compile your code (and/or activate `flymake-mode`
when editing your Elisp code) and pay attention to the warnings you get
from it.


        Stefan

Re: lexical binding?

[Jean-Christophe Helary]

> On Oct 24, 2021, at 22:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Also, remember to byte-compile your code (and/or activate `flymake-mode`
> when editing your Elisp code) and pay attention to the warnings you get
> from it.

Thank you for the suggestiongs, and I hope you did not weep too hard :)

I'm seeing flymake suggests things about what I should do in the first lines of my code (comments, etc.)
Where does it find its rules ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: lexical binding?

[Stefan Monnier]

> I'm seeing flymake suggests things about what I should do in the first lines
> of my code (comments, etc.)
> Where does it find its rules ?

It should be in the emacs lisp manual, but I think it depends on
the specifics.


        Stefan

Re: lexical binding?

[Jean-Christophe Helary]

> On Oct 24, 2021, at 22:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> 
> Also, remember to byte-compile your code (and/or activate `flymake-mode`
> when editing your Elisp code) and pay attention to the warnings you get
> from it.

flymake is really nice :-)

But it says "fifth is not known to be defined" then suggest that I change to "cl-fifth" and then gives me the same warning.

Is there something I need to know here ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: lexical binding?

[Stefan Monnier]

Jean-Christophe Helary [2021-10-25 23:46:04] wrote:
>> On Oct 24, 2021, at 22:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Also, remember to byte-compile your code (and/or activate `flymake-mode`
>> when editing your Elisp code) and pay attention to the warnings you get
>> from it.
>
> flymake is really nice :-)
>
> But it says "fifth is not known to be defined" then suggest that I change to
> "cl-fifth" and then gives me the same warning.
>
> Is there something I need to know here ?

For your file to be sure that `cl-fifth` exists, it needs to have

    (require 'cl-lib)

somewhere near the beginning.
Personally, I recommend (nth 4 <...>) instead ;-)


        Stefan

Re: lexical binding?

[Michael Heerdegen]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

> What is the issue with using setq on undefined symbols? Can that break
> things eventually?

If you do this, it will soon become impossible to find out
when the values of referenced variables were set and by what code.  Such
a programming style would lead to unreadable and hard-to-debug code.
Not because others are not used to this kind of style - it's really
harder to do.

> Is that related to lexical binding?

Not really.  You have dynamically binding global variables in both the
lexical binding and the dynamically binding dialect of Elisp, and what
you suggest leads to the same problems in both dialects.

OTOH, it is a bit related.  Bindings to lexical variables can be tracked
most easily by a programmer - you can just look at the text to see where
in your code a binding is established.

Dynamical variables are worse, but it's still easy to track dynamical
bindings using a debugger.  You must just look for binding forms
currently processed in the backtrace, and which function called them.

Only using dynamically binding global variables is the most primitive
way of handling computer memory.  Calculators from the 90s had this:
global registers A, ..., Z.  You can't even write recursive functions
using only a limited number of global variables.  And a debugger doesn't
help you much understanding such code.  You must run the complete
program and track set variables to understand what is going on.

So this kind of thing should be avoided wherever possible.

Michael.