Hendrik Boom <hendrik@???> writes:

> On Tue, May 24, 2016 at 02:47:04PM +0100, Rainer Weikusat wrote:
>> Didier Kryn <kryn@???> writes:
>> > Le 23/05/2016 23:29, Rainer Weikusat a écrit :
>> >> Rainer Weikusat <rweikusat@???> writes:
>> >>> Emacs is a somewhat old-fashioned/ traditional[*] Lisp implemenation
>> >> [*] It doesn't support lexical scoping.
>> >     No idea what that means.

[...]

>> (defun 1+x () (1+ x))
>> -> 1+x

[...]

>> (defun 1+v (v)
>>   (let
>>       ((x v))
>>     (1+x)))
>> -> 1+v

>>
>> (setq x 15)
>> 15

[...]

>> (1+v 4)
>> -> 5

[...]

> Note: This example describes dynamic scoping. The call to (1+x) uses
> the x that's active where it is called, not where it is defined.
> In lexical scoping, it would always use the x where it is defined, no
> matter what extraneous x's are around where it is called.

The example was supposed to show dynamic scoping but that's something
subtly different from what you're writing about. In the example above,
the 1+x function does a computation involving a free variable named
x. The 1+v functions binds the symbol x to the value passed as
argument. Because elisp (up to version 24.1) - as all mainstream
variants (whether or not the term 'mainstream lisp variant' make much
sense could be discussed) prior to Common Lisp - does dynamic scoping,
this binding is visible to all code executed while it is 'alive' at run
time, that is (in absence of multi-threading) all code textually
contained in the body of the expression which established the binding
and all function called from this code, functions called from functions
called from this code and so on. Hence, the 1+x call sees the binding
established by 1+v and returns the intended result despite there's also
a "global" value of x (15). In Common Lisp, the value bound to x by 1+v
wouldn't be visible to 1+x unless x was declared special.

What you're referring to ...


>> 'Lexical scoping' (which works the way 'local variables' usually work in
>> other languages) didn't exist in the 'Lisp world' until Scheme came to
>> be.
>
> Not quite. In Lisp 1.5 way back in the 60's they realised absence of
> lexical scope was a problem, and invented a wrapper called FUNCTION that
> you placed around a lambda expression that would make the enclosed lamda
> expression lexically scoped.

... and what the Lisp 1.5 FUNCTION was about was to enable solving the
so-called 'upward funarg problem': Assuming a function is returned
(passed upward) when evaluating an expression and later activated in a
different context, what are free variables used by the returned function
supposed to refer to, the values they had at the time when the function
was defined or the values they had when the function is activated? Eg,
assuming this code,

--------
(setq seq-2 (let
        ((cur 2)) 
          (lambda () (setq cur (1+ cur)))))

(let ((cur 15))
(dotimes (x 10) (print (funcall seq-2))))
---------

should this print the numbers 3 - 12 or 16 - 25? The former happens with
Common Lisp, the latter with elisp. Lisp 1.5 supported either behaviour
despite it didn't do lexical scoping (FUNCTION was supposed to request
the first alternative).