Re: Lexical and Dynamic Scope

Re: Lexical and Dynamic Scope

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Stefan and the Emacs maintainers added lexical scope
> because it makes Emacs Lisp faster and it's simpler
> to understand.

OK, this post made it much clearer... So lexical scope
is like in C exactly as I thought.

Dynamic scope is when you actually don't have a scope
(?) - you have a stack of variable names and when you
refer (read) to a variable name you get the latest, and
that can be put there by whoever.

But: is the stack of names global? Howcome all the Lisp
don't get crazy from other Lisp changing "its"
variables? But come to think of it, I very seldom use
variables - I use `let's, and perhaps that is both a
shield from interference and doesn't change the global
name stack?

-- 
underground experts united

Re: Lexical and Dynamic Scope

[Aurélien Aptel]

On Sun, Jul 20, 2014 at 9:47 PM, Emanuel Berg <embe8573@student.uu.se> wrote:
> But: is the stack of names global? Howcome all the Lisp
> don't get crazy from other Lisp changing "its"
> variables? But come to think of it, I very seldom use
> variables - I use `let's, and perhaps that is both a
> shield from interference and doesn't change the global
> name stack?

In dynamic scoping, each time you nest a let binding to same symbol
you add to this variable stack. When you take the value of a symbol
the value comes from the top of the stack of this symbol.

    (defvar a 1)
    (defun my-a ()
      "Return current value of a (top top the stack)"
      a)

    (my-a)
    => 1

    (let ((a 2)) ;; push 2 in the `a' stack
      ;; we usually say: a is shadowed in this scope
      (my-a))
    => 2

    ;; at the end of let scope, 2 is popped from the stack
    (my-a)
    => 1

    (list
     (my-a)

     (let ((a 2))
       (my-a))

     (let ((a 3))
       (let ((a 4))
         (my-a)))

     (my-a))
    => (1 2 4 1)

Re: Lexical and Dynamic Scope

[Emanuel Berg]

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> writes:

> In dynamic scoping, each time you nest a let binding
> to same symbol you add to this variable stack. When
> you take the value of a symbol the value comes from
> the top of the stack of this symbol.

The code you sent is somewhat unclear. When the
(presumed) programmer writes `my-a', it is somewhat
the assumption that what is intended is the global
variable, because there isn't any other `a' around. (To
use global variables and return them from functions at
that - but OK, it is an example to show the principle,
I get that.)

On the other hand, in the `let' clauses, it is far from
clear that `my-a' will even be affected as in those
clauses, there isn't even an `a' mentioned.

I actually think that `my-a' shouldn't be affected!
When I use `let', it is just to make the code easy to
write, read, and change, and any code invoked from the
`let' list that happens to refer to some entity with
the same name shouldn't be affected.

I never use `defvar', but sometimes `setq'.

I use `setq' in most cases when two functions need to
work on some shared file or buffer name, and I want
that set in one place, where I to change it - it is not
part of the interface to other functions or Emacs in
general, so I would declare it restricted to those two
defuns did I know a practical way.

I use `let' and function parameters and I expect those
to always be prioritized before any global or otherwise
more distant entities with the same names. If the
`let's are nested, or if they share the same name as
one of the parameters - both situations I consider
confusing and haven't done ever, I think - but OK, in
those cases I expect the most recent mention (in the
code) to hold. I don't expect `let' to affect any other
code than the code in the `let' list itself, where
references to the bound name will be replaced for the
corresponding data.

The only time I had problems with this is when I setup
lambdas using bindings from `let' and function
parameters. Apparently the lambdas disassociated
themselves from those bindings, and instead looked for
global variables. OK, I know that now so that won't
happen again.

-- 
underground experts united

Re: Lexical and Dynamic Scope

[Stefan Monnier]

> code) to hold. I don't expect `let' to affect any other
> code than the code in the `let' list itself, where
> references to the bound name will be replaced for the
> corresponding data.

This is pretty much the definition of "lexical scoping".


        Stefan

Re: Lexical and Dynamic Scope

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I don't expect `let' to affect any other code than
>> the code in the `let' list itself, where references
>> to the bound name will be replaced for the
>> corresponding data.
>
> This is pretty much the definition of
> "lexical scoping".

OK, I am convinced. But to put that initial line
everwhere - I guess a script could do that for a bunch
of Elisp files... still - it's a bit "C preprocessor",
don't you think? What I could see it isn't "transitive"
so if you put it in one file and make a `load' from
that file I get the same old. Do you have a
(load-lexical ...) planned for?

-- 
underground experts united

Re: run-with-timer does not display message

[Stefan Monnier]

> Because they can be encoded different things it makes sense calling
> this lexical (because the value is simply read, not looked up) and not
> "static".

It's also called "static scoping".  And the name doesn't have much to do
with the implementation technique used.  It's called "lexical" because
the way a particular identifier use is matched to a particular variable
only depends on the shape of the program text rather than depending on
its run-time behavior.

> This corresponds to an extent to
> call-by-value/call-by-reference,

No.  CBV/CBR/CBN are orthogonal concepts to static/dynamic scoping.

> 1. How do I put Emacs in lexical mode? Do I do that

Put -*- lexical-binding:t -*- somewhere on the first line of your Elisp file.


        Stefan

Lexical and Dynamic Scope

[Robert Thorpe]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Because they can be encoded different things it makes sense calling
>> this lexical (because the value is simply read, not looked up) and not
>> "static".
>
> It's also called "static scoping".  And the name doesn't have much to do
> with the implementation technique used.  It's called "lexical" because
> the way a particular identifier use is matched to a particular variable
> only depends on the shape of the program text rather than depending on
> its run-time behavior.

I'll elaborate a bit....  What we're talking about here is where
variables are visible.  How those variables behave is a different
question.  They could only hold one type (classical static typing), hold
a set of types or hold any type ("dynamic" typing) depending on the
language.

Most languages have lexical scope.  The scope of a variable is defined
by a part of the program text.  For example, a variable Bar is defined
in a function Foo.  That means Bar is visible within Foo only.  The
section of text defines where variables can be accessed, that's why it's
called "lexical" or "static".  There can be multiple levels of lexical
scoping, for example in C some variables are visible everywhere in a
file.  One way of thinking about it is by thinking of a stack.  The
current lexical area and everything defined in it is the top of the
stack.  When the code exits that area that place on the stack disappears
(it's popped).  When a function call occurs a new entry on top of the
stack is created (a push).

Dynamic scope means that visibility follows code execution.  If a
variable Baz is defined by code executed in the past then it's visible
by present code.  If a local variable called Baz is defined then it's
used instead of the more global one.  The "higher level" value continues
to exist.  This can be thought of using stacks too, in a slightly
different way.  In the dynamic case there's a stack for every
*variable name*.  If a local variable is defined for a name that's
already used then a new value is pushed on the stack of variable values
and removed when the local area ends.

Stefan and the Emacs maintainers added lexical scope because it makes
Emacs Lisp faster and it's simpler to understand.

BR,
Rob