Noam Postavsky <npostavs@users.sourceforge.net> writes:

> Noam Postavsky <npostavs@users.sourceforge.net> writes:
>
>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>
>>>> I noticed doing (let () (defvar x)) seems to be the same as (progn
>>>> (defvar x)), which may be a bug.
>>>
>>> Both interpretations would make sense, so given the lack of
>>> documentation about the intention, we could consider it as a feature as
>>> much as a bug.
>>>
>>> Have you checked whether the behavior is the same with the
>>> byte-compiler?
>>
>> Yes, it's the same.
>
> It's the same when let-binding a lexical variable, but not when binding
> a dynamic one.
>
>     ;; -*- lexical-binding: t -*-
>
>     (defvar foo-dynamic 'foo)
>
>     (let ((foo-dynamic 99))
>       (defvar x))
>
>     (let ((x 1))
>       (setq testfun (lambda () x)))
>
>     (message "%S" (funcall testfun))
>
> gives
>
>     Symbol’s value as variable is void: x
>
> when running the interpreted version, and
>
>     1
>
> when running the compiled version.

This let-block thing feels more like a bug to me, so I'm inclined to
leave it out of the manual.  I'm also not so sure about putting in
examples into the manual; the shortest and simplest I could come up with
is this, but I don't know that it's worth putting in.

    This example demonstrates the effects of using @code{defvar} without
    an initial value:

    @example
    @group
    (let ((x 'lexical))
      (defun get-lexical-x ()
        x))
    (defvar x)
    (defun get-dynamic-x ()
      x)

    (let ((x 'dynamic))
      (list (get-dynamic-x)
            (get-lexical-x)))
         @result{} (dynamic lexical)
    @end group
    @end example

Here's the patch I have in my local repo right now: