Tasks not suitable for dynamic coverage

Can you give me some examples of tasks unsuitable for dynamically covered Lisp? I don’t understand how lexical coverage is much better, and not just a question of changing the coding style, so I would like to code something and see it with my own eyes.

Thanks!

+6
scope lisp scheme elisp
source share
2 answers
(define (add n) (lambda (m) (+ nm))) (define add4 (add 4)) (map (add 7) (list 1 2 3)) 

But this is just one small random example. If you dig far enough, you will find several tons of additional reasons. For a more detailed discussion, you should really go through some kind of tutorial. My recommendation for this would be PLAI .

Here's another demo:

 (define tax 0.17) (define (add-tax amt) (+ amt (* amt tax))) 

add-tax seems to be a function that returns a given amount with the correct tax rate, but you can never rely on it. For example, it could be called like this:

 (let ((tax -0.17)) (add-tax 100)) 

and you will get completely wrong answers. But it’s even worse if your language is really dynamically limited: you cannot rely on any bindings, including functions. Consider this:

 (let ((+ -)) (add-tax 100)) 

Both BTW Elisp and CL do not suffer from this problem so directly, using such things as a double namespace and shadow copy rules of "built-in" bindings.

+7
source share

Worth reading the Wikipedia article on scope .

Functionally, this only matters when you have variables that are not related in the current scope. So, if you do not have free variables, it does not matter.

Eliz Barzilay answer is a good example of a lambda with a function that has a character ( n ) that will have a different binding in the dynamic / static area.

From what I know, lexical-spoken languages ​​can be compiled a little more, because at compile time the compiler can determine all the variable references, unlike the dynamic region, which should look for a variable reference at run time.

0
source share

All Articles