Re: DynamicBindingVsLexicalBinding

Re: DynamicBindingVsLexicalBinding

[Barry Margolin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

In article <mailman.3891.1381600459.10748.help-gnu-emacs@gnu.org>,
 Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> Hi,
> 
> in article
> 
> http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding
> 
> it's said WRT lexical binding
> 
> "Because it's (1) much easier for the user [that is, programmer], because
> it eliminates the problem of which variables lambda-expressions use
> (when they attempt to use variables from their surrounding context)"
> 
> Unfortunately couldn't find a use-case where it is easier - while consenting 
> it might be easier for the compiler to swallow.
> 
> Could someone give an example, where lexical binding makes coding easier?
> 
> TIA,
> 
> Andreas

Here's one of the canonical examples:

(let ((i 'foo))
  (mapcar #'(lambda (x) (list i x))
          some-list))

Now suppose this were the definition of mapcar (I'm simplifying it to 
take just one list argument):

(defun mapcar (function list)
  (let ((result nil))
    (dolist (i list)
      (push result (funcall function i)))
    (nreverse result)))

Notice that mapcar also uses a variable "i". In a dynamically-scoped 
Lisp, this would shadow the variable in the above code.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

DynamicBindingVsLexicalBinding

[Andreas Röhler]

Hi,

in article

http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding

it's said WRT lexical binding

"Because it's (1) much easier for the user [that is, programmer], because
it eliminates the problem of which variables lambda-expressions use
(when they attempt to use variables from their surrounding context)"

Unfortunately couldn't find a use-case where it is easier - while consenting it might be easier for the compiler to swallow.

Could someone give an example, where lexical binding makes coding easier?

TIA,

Andreas

Re: DynamicBindingVsLexicalBinding

[Dmitry Gutov]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding
>
> it's said WRT lexical binding
>
> "Because it's (1) much easier for the user [that is, programmer], because
> it eliminates the problem of which variables lambda-expressions use
> (when they attempt to use variables from their surrounding context)"
>
> Unfortunately couldn't find a use-case where it is easier - while consenting it might be easier for the compiler to swallow.
>
> Could someone give an example, where lexical binding makes coding easier?

Consider this rather obvious higher-order function:

(defun addinator (a)
  (lambda (b)
    (+ a b)))

;; This doesn't work with dynamic binding, at all
(funcall (addinator 3) 4)

;; This returns wrong result with dynamic binding
(let ((a 42))
  (funcall (addinator 3) 4))

RE: DynamicBindingVsLexicalBinding

[Drew Adams]

> Consider this rather obvious higher-order function:
> (defun addinator (a) (lambda (b) (+ a b)))
> 
> ;; This doesn't work with dynamic binding, at all
> (funcall (addinator 3) 4)
> 
> ;; This returns wrong result with dynamic binding
> (let ((a 42)) (funcall (addinator 3) 4))

Actually, both examples "work" with dynamic binding.  They do
exactly the code says they do.  They simply work according to
dynamic binding rules, not lexical binding rules.

What is wrong is to expect lexical binding behavior without
lexical binding!

Both correctly raise an error if `a' has no value.  `a' is a
free variable in your examples, when using dynamic binding.
and both work correctly, per dynamic binding behavior, if you
first give `a' a value, e.g., (setq a 9).

They just do not do what they would do with lexical binding;
that's all.

(setq a 9) ; Current dynamic value of `a' is 9.

(defun addinator (a) (lambda (b) (+ a b)))
  ; That's (lambda (b) (+ a b)), a program that looks up
  ; `a' in the current dynamic environment, adds it to
  ; passed argument `b', and returns the result.

(funcall (addinator 3) 4)
  ; That calls the result of (addinator 3) with argument 4.
  ; Which means it calls (lambda (b) (+ a b)) with arg 4.
  ; Which looks up the current dynamic binding of `a', which
  ; is 9, adds it to 4, and returns the result correctly: 13.

(let ((a 42)) (funcall (addinator 3) 4))
  ; That binds `a' to 42, changing the current dynamic binding
  ; of `a' to 42.  Then it calls (addinator 3) with arg 4.
  ; Which adds the current dynamic binding of `a', which is 42,
  ; to `b'.  The result is correct: 46.

`addinator' has this definition:
(lambda (a) (function (lambda (b) (+ a b))))

This is *not* a closure in Emacs Lisp.  It is a function whose
body is a *quoted* lambda expression that has a free variable,
`a'.  That free variable is looked up when that body function
is applied, not when `addinator' is defined.

The only thing wrong here is your mistaken expectation (and
the attendant naming of function `addinator').

IOW, the error is in looking for noon at 2:00: "chercher midi à quatorze heures".

Yes, it can be confusing.  No, dynamic binding is not very close
to functional programming or lambda calculus.  But it is not
wrong.  It just plays by different rules.

Using Emacs Lisp, like using Common Lisp, requires understanding
both kinds of behavior.

Yes, one can choose not to use any dynamically scoped variables.
Or one can choose not to use any lexically scoped variables.
Such a choice can simplify what one needs to understand.

"[I]t eliminates the problem of which variables lambda-expressions
use (when they attempt to use variables from their surrounding
context)."

That elimination happens with either simplification: stick to
dynamic-only or stick to lexical-only.  The difference between
the two eliminations is that with lexical scope you need only
look at the immediate code; whereas with dynamic scope you need
to think about time/state to understand the behavior.

And yes, it is generally easier to determine lexical scope
than dynamic scope: lexical means WYSIWYG.

But the language provides both, and learning the language means understanding both and how they can be used together.

Re: DynamicBindingVsLexicalBinding

[Thien-Thi Nguyen]

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

Re: DynamicBindingVsLexicalBinding

[Andreas Röhler]

Am 12.10.2013 20:35, schrieb Dmitry Gutov:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding
>>
>> it's said WRT lexical binding
>>
>> "Because it's (1) much easier for the user [that is, programmer], because
>> it eliminates the problem of which variables lambda-expressions use
>> (when they attempt to use variables from their surrounding context)"
>>
>> Unfortunately couldn't find a use-case where it is easier - while consenting it might be easier for the compiler to swallow.
>>
>> Could someone give an example, where lexical binding makes coding easier?
>
> Consider this rather obvious higher-order function:
>
> (defun addinator (a)
>    (lambda (b)
>      (+ a b)))
>
> ;; This doesn't work with dynamic binding, at all
> (funcall (addinator 3) 4)
>
> ;; This returns wrong result with dynamic binding
> (let ((a 42))
>    (funcall (addinator 3) 4))
>


That's interesting, but can hand-over functions also with dynamic binding.

Do you have a real use-case where lexical-binding is superior?

Can't see goodies from lexical binding beside a simplification for the compiler.

Re: DynamicBindingVsLexicalBinding

[Kai Großjohann]

Andreas Röhler wrote:
> 
> That's interesting, but can hand-over functions also with dynamic binding.
> 
> Do you have a real use-case where lexical-binding is superior?
> 
> Can't see goodies from lexical binding beside a simplification for the
> compiler.

I think the key benefit is that lexical binding allows you to support
closures, and with closures you can do cool things.

In Node.js, you need to use closures for everything, due to its
programming model.  For example, when you query a DB in Node.js, you
call a function passing it the query and another function to process the
results:  queryDb(sql, callback);
Here, it is incredibly useful for "callback" to have access to local
variables at the point where queryDb is called.  (I mean variables that
are local to where queryDb is called.)

Some GUI frameworks allow you to specify a function to be called when
the user presses a button, and here, too, it's nice for the function to
have access to local variables from where the button was created.

In Emacs, you write functions to be called when the user presses a key,
and here the solution is that all the variables that the function needs
are buffer-local.

Of course, with dynamic binding you can do other cool things (you can
let-bind a variable, then call a function which calls a function which
calls yet other functions, and the innermost function will reference the
value you just bound -- so you can pass parameters around without
actually having to mention them on every function call).  So each of the
styles has their own advantage.

I find that the idea that variables declared specially (e.g. with
defvar) can be dynamically bound whereas everything else is lexically
bound by default -- this idea is quite useful.  For if you want to
dynamically bind something to influence another function, you need to
know which variables that other function uses -- and defvar is a good
way to document this.

Kai

RE: DynamicBindingVsLexicalBinding

[Drew Adams]

> lexical binding allows you to support closures, and with closures
> you can do cool things.

Yes.  And they remove "funarg" problems.

> with dynamic binding you can do other cool things (you can let-bind
> a variable, then call a function which calls...and the innermost
> function will reference the value you just bound -- so you can pass
> parameters around without actually having to mention them on every
> function call).

Yes.  Which is especially important for a heavily interactive and
customizable program such as Emacs.  Emacs users extend and otherwise
modify or adapt the source code, and they do so sometimes on the fly
and interactively.

And that's not only a good thing instead of a bad thing.  It is
practically the raison d'etre of Emacs: It is a user Lisp environment
(which offers editor/UI objects such as buffers and windows).

> So each of the styles has their own advantage.

Definitely.  Those who imagine that a lexical-only approach, a la
Scheme, would be a better way to go for Emacs are on the wrong track,
IMHO.

> I find that the idea that variables declared specially (e.g. with
> defvar) can be dynamically bound whereas everything else is
> lexically bound by default -- this idea is quite useful.  For if
> you want to dynamically bind something to influence another
> function, you need to know which variables that other function uses
> -- and defvar is a good way to document this.

Yes, again.  Common Lisp showed how to have lexical and dynamic
scope cohabit the same programming language.  Its approach to this is
still a good model to follow.

Now if only Emacs Lisp had good namespace control, like Common-Lisp
packages...

Re: DynamicBindingVsLexicalBinding

[Phillip Lord]

Drew Adams <drew.adams@oracle.com> writes:
>> with dynamic binding you can do other cool things (you can let-bind
>> a variable, then call a function which calls...and the innermost
>> function will reference the value you just bound -- so you can pass
>> parameters around without actually having to mention them on every
>> function call).
>
> Yes.  Which is especially important for a heavily interactive and
> customizable program such as Emacs.  Emacs users extend and otherwise
> modify or adapt the source code, and they do so sometimes on the fly
> and interactively.

I don't think this is an advantage of dynamic binding; it's just an
advantage of having lots of configuration options. 

I've certainly used the feature that Kai likes, but mostly it has been
to hack around code which I do not control or do not want to change.
Nowadays, in general, I would want to advice code instead.


>> So each of the styles has their own advantage.
>
> Definitely.  Those who imagine that a lexical-only approach, a la
> Scheme, would be a better way to go for Emacs are on the wrong track,
> IMHO.

I am not convinced that having two complete separate models of variable
binding is a great idea. This forces Emacs programmers to have a good
understanding of dynamic and lexical scope. If Emacs is to move more
toward lexical scope, then supporting both should be considered only to
be a stepping stone.


> Now if only Emacs Lisp had good namespace control, like Common-Lisp
> packages...


A good point, but an independent one I think!

RE: DynamicBindingVsLexicalBinding

[Drew Adams]

> > Yes.  Which is especially important for a heavily interactive and
> > customizable program such as Emacs.  Emacs users extend and
> > otherwise modify or adapt the source code, and they do so sometimes
> > on the fly and interactively.
> 
> I don't think this is an advantage of dynamic binding; it's just an
> advantage of having lots of configuration options.

Which are dynamically bound variables.  Perhaps you are not as lexical
as you think. ;-)

Do you mean that you are OK with assigning values to such global,
dynamically bound variables at startup time, and you are OK with a
user changing their values interactively anytime (e.g. using Customize),
but you are not OK with code let-binding global, dynamically bound
variables?  Assignment is OK by you, but not let-binding?

> I've certainly used the feature that Kai likes, but mostly it has
> been to hack around code which I do not control or do not want to
> change.  Nowadays, in general, I would want to advice code instead.

http://www.gnu.org/software/emacs/emacs-paper.html#SEC17  (Richard
Stallman, 1981), including:

"Formal Parameters Cannot Replace Dynamic Scope

 Some language designers believe that dynamic binding should be avoided,
 and explicit argument passing should be used instead. Imagine that
 function A binds the variable FOO, and calls the function B, which
 calls the function C, and C uses the value of FOO. Supposedly A should
 pass the value as an argument to B, which should pass it as an argument
 to C. 

 This cannot be done in an extensible system, however, because the author
 of the system cannot know what all the parameters will be. Imagine that
 the functions A and C are part of a user extension, while B is part of
 the standard system. The variable FOO does not exist in the standard
 system; it is part of the extension. To use explicit argument passing
 would require adding a new argument to B, which means rewriting B and
 everything that calls B. In the most common case, B is the editor
 command dispatcher loop, which is called from an awful number of places. 

 What's worse, C must also be passed an additional argument. B doesn't
 refer to C by name (C did not exist when B was written). It probably
 finds a pointer to C in the command dispatch table. This means that
 the same call which sometimes calls C might equally well call any
 editor command definition. So all the editing commands must be
 rewritten to accept and ignore the additional argument. By now, none
 of the original system is left!"

Re: DynamicBindingVsLexicalBinding

[Phillip Lord]

Drew Adams <drew.adams@oracle.com> writes:

>> > Yes.  Which is especially important for a heavily interactive and
>> > customizable program such as Emacs.  Emacs users extend and
>> > otherwise modify or adapt the source code, and they do so sometimes
>> > on the fly and interactively.
>> 
>> I don't think this is an advantage of dynamic binding; it's just an
>> advantage of having lots of configuration options.
>
> Which are dynamically bound variables.  Perhaps you are not as lexical
> as you think. ;-)
>
> Do you mean that you are OK with assigning values to such global,
> dynamically bound variables at startup time, and you are OK with a
> user changing their values interactively anytime (e.g. using Customize),
> but you are not OK with code let-binding global, dynamically bound
> variables?  Assignment is OK by you, but not let-binding?


Well, users don't change their values anytime. For a start, they can
only change them when the interpreter is not doing anything else. An,
they tend not to do this often.

As far as I can see, something like the dynamic behaviour of let is
always possible in a lexical binding environment -- you just push the
global value onto a stack, and pop it off again afterwards; what can be
done by the lisp interpreter can be done in lisp also.

Do I like changing values of variables underneath the nose of a
function; in general, no, because I think it is a little unpredictable.

> http://www.gnu.org/software/emacs/emacs-paper.html#SEC17  (Richard
> Stallman, 1981), including:
>
> "Formal Parameters Cannot Replace Dynamic Scope
>
>  Some language designers believe that dynamic binding should be avoided,
>  and explicit argument passing should be used instead. Imagine that
>  function A binds the variable FOO, and calls the function B, which
>  calls the function C, and C uses the value of FOO. Supposedly A should
>  pass the value as an argument to B, which should pass it as an argument
>  to C. 

I haven't heard RMS talk about this recently, but 30 years ago is a
long time. One simple, alternative, solution to the problem is to pass
around a single map between A, B and C. Not often done in elisp, but
very common in R for instance, where functions will pass graphics
contexts around until it gets to someone who cares. 

Phil

Re: DynamicBindingVsLexicalBinding

[Kai Großjohann]

Phillip Lord wrote:
> 
> I've certainly used the feature that Kai likes, but mostly it has been
> to hack around code which I do not control or do not want to change.
> Nowadays, in general, I would want to advice code instead.

Here is a nice and straightforward application of dynamic binding (if I
do say so myself).

(defun perldoc ()
  (interactive)
  (require 'man)
  (let ((manual-program "perldoc"))
    (call-interactively 'man)))

The part where it does call-interactively is pretty ugly (but the full
interactive spec of the man function is even worse).

Of course a REAL developer would provide a manual reader class with
configurable manual reader class factories, and then use a dependency
injection container to implement a configurable manual reader class
factory factory.  And because convention over configuration is a good
thing, we'll say that the ManManualReaderFactory creates "man" manual
readers whereas the PerldocManualReaderFactory creates "perldoc" manual
readers.  So you can write a manual reader factory factory generator
that just generates an empty subclass of the
AbstractManualReaderFactoryBase at runtime.  Yeah.  That would be great.
 You would even only need a few hundred lines of code to do it.  And the
Spring dependency injection container to go with it is only a couple MB.
 What's not to like about this?  What?  The Emacs Lisp solution is only
five lines of code you say?  How can this _possibly_ provide the same
functionality that we've got with our awesome enterprisey framework?
Hm?  Dynamic binding?  You must be kidding!

Kai

Re: DynamicBindingVsLexicalBinding

[Phillip Lord]

Kai Großjohann <kai.grossjohann@gmx.net> writes:
> Here is a nice and straightforward application of dynamic binding (if I
> do say so myself).
>
> (defun perldoc ()
>   (interactive)
>   (require 'man)
>   (let ((manual-program "perldoc"))
>     (call-interactively 'man)))

It is a nice example, and I've done something similar myself (on
smtpauth, and w3 if I remember).


> Of course a REAL developer would provide a manual reader class with
> configurable manual reader class factories, and then use a dependency
> injection container to implement a configurable manual reader class
> factory factory.  And because convention over configuration is a good
> thing, we'll say that the ManManualReaderFactory creates "man" manual
> readers whereas the PerldocManualReaderFactory creates "perldoc" manual
> readers.  So you can write a manual reader factory factory generator
> that just generates an empty subclass of the
> AbstractManualReaderFactoryBase at runtime.  Yeah.  That would be great.
>  You would even only need a few hundred lines of code to do it.  And the
> Spring dependency injection container to go with it is only a couple MB.
>  What's not to like about this?  What?  The Emacs Lisp solution is only
> five lines of code you say?  How can this _possibly_ provide the same
> functionality that we've got with our awesome enterprisey framework?
> Hm?  Dynamic binding?  You must be kidding!


Like this class which is a bit of a classic.

http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

and has been described as everything wrong with Java in a single class.


None the less, I think you are hitting a strawman here; if Emacs went
entirely lexically bound, I don't think that it necessarily follows that
elisp will turn into Java.

Phil

Re: DynamicBindingVsLexicalBinding

[Kai Großjohann]

Phillip Lord wrote:
> 
> None the less, I think you are hitting a strawman here; if Emacs went
> entirely lexically bound, I don't think that it necessarily follows that
> elisp will turn into Java.

Sorry, Phil, that's not what I meant.  I think I got carried away a
little there.  Even if Emacs were to move to Guile: Scheme has fluid-let.

All I wanted to point out is that this idea of dynamic binding is more
powerful than one might think at first.

Kai

Re: DynamicBindingVsLexicalBinding

[Phillip Lord]

Kai Großjohann <kai.grossjohann@gmx.net> writes:
> Phillip Lord wrote:
>> 
>> None the less, I think you are hitting a strawman here; if Emacs went
>> entirely lexically bound, I don't think that it necessarily follows that
>> elisp will turn into Java.
>
> Sorry, Phil, that's not what I meant.  I think I got carried away a
> little there.

Not at all. It was very poetic!

> Even if Emacs were to move to Guile: Scheme has fluid-let.
>
> All I wanted to point out is that this idea of dynamic binding is more
> powerful than one might think at first.


Perhaps my understanding is not complete, but I always thought that
dynamic and static binding was about variables that are unbound. If we
have global variables with mutable state, then as far as I can see, you
could do something equivalent with either.

So, this...

(defun perldoc ()
  (interactive)
  (require 'man)
  (let ((manual-program "perldoc"))
    (call-interactively 'man)))

is nearly equivalent to 

(defun perldoc()
  (interactive)
  (require 'man)
  (let ((old manual-program))
    (setq manual-program "perldoc")
    (call-interactively 'man)
    (setq manual-program old))


If we were multi-threaded, then AFAICT, the let version would be
cleaner -- as the altered manual-program is *only* in the dynamic
environment of the call to the perldoc command. So another call to the
man function would be unaffected. While the second changes global state,
and then changes it back. But, we aren't.

Phil

Re: DynamicBindingVsLexicalBinding

[Barry Margolin]

In article <mailman.4127.1381928277.10748.help-gnu-emacs@gnu.org>,
 phillip.lord@newcastle.ac.uk (Phillip Lord) wrote:

> Perhaps my understanding is not complete, but I always thought that
> dynamic and static binding was about variables that are unbound. If we
> have global variables with mutable state, then as far as I can see, you
> could do something equivalent with either.
> 
> So, this...
> 
> (defun perldoc ()
>   (interactive)
>   (require 'man)
>   (let ((manual-program "perldoc"))
>     (call-interactively 'man)))
> 
> is nearly equivalent to 
> 
> (defun perldoc()
>   (interactive)
>   (require 'man)
>   (let ((old manual-program))
>     (setq manual-program "perldoc")
>     (call-interactively 'man)
>     (setq manual-program old))
> 
> 
> If we were multi-threaded, then AFAICT, the let version would be
> cleaner -- as the altered manual-program is *only* in the dynamic
> environment of the call to the perldoc command. So another call to the
> man function would be unaffected. While the second changes global state,
> and then changes it back. But, we aren't.

You also need unwind-protect to ensure that the value is reverted if the 
code aborts.

With that fix, it's essentially how most implementations of dynamic 
binding worked in single-threaded Lisps. But multi-threaded Lisps need 
to add hooks into thread switching.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: DynamicBindingVsLexicalBinding

[Rustom Mody]

On Sunday, October 13, 2013 9:51:33 PM UTC+5:30, Drew Adams wrote:

> Definitely.  Those who imagine that a lexical-only approach, a la
> Scheme, would be a better way to go for Emacs are on the wrong track,
> IMHO.

You can have dynamic scoping in scheme if you want
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-7.html#node_sec_5.2

Re: DynamicBindingVsLexicalBinding

[Phillip Lord]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> in article
>
> http://www.emacswiki.org/emacs/DynamicBindingVsLexicalBinding
>
> it's said WRT lexical binding
>
> "Because it's (1) much easier for the user [that is, programmer], because
> it eliminates the problem of which variables lambda-expressions use
> (when they attempt to use variables from their surrounding context)"
>
> Unfortunately couldn't find a use-case where it is easier - while consenting it might be easier for the compiler to swallow.
>
> Could someone give an example, where lexical binding makes coding easier?


The point is that you can determine, by reading the code, where the
value of a variable could be changed. You cannot do this with dynamic
binding, because it depends on the execution path.

As a second point, lexical scoping gives you closures which are nice.

Interesting, although lexical binding is pretty much standard now,
exceptions have the same problems (and benefits) as dynamic binding; you
cannot tell where an exception will be handled by looking at the code.

Phil