unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#33828: 26.1; Unbound defvar across compilation units
@ 2018-12-21 12:02 Luís Oliveira
  2018-12-21 13:50 ` Luís Oliveira
  2018-12-21 20:02 ` Eli Zaretskii
  0 siblings, 2 replies; 7+ messages in thread
From: Luís Oliveira @ 2018-12-21 12:02 UTC (permalink / raw)
  To: 33828; +Cc: João Távora

Hello,

I think I've come across a bug.

    $ cat f1.el
    ;;; f1.el ---                                        -*-
lexical-binding: t; -*-
    ;;; Lexical binding is set to T, but the bug happens regardless.

    (defvar my-special)

    (provide 'f1)


    $ cat f2.el
    ;;; f2.el ---                                        -*-
lexical-binding: t; -*-

    (require 'f1)

    (defun f2-foo ()
      (let ((my-special 123))
        (f2-bar)))

    (defun f2-bar ()
      my-special)

    (print (f2-bar))



    $ emacs -Q -L . -f batch-byte-compile f2.el

    In toplevel form:
    f2.el:5:1:Warning: Unused lexical variable `my-special'

    In f2-bar:
    f2.el:10:3:Warning: reference to free variable `my-special'


Also:

    $ emacs -Q -L . -batch -l f2.el
    Symbol's value as variable is void: my-special


Changing f1.el's defvar to have an initial value makes the problem go
away, but this behaviour was unexpected to me. Moving defvar inside
f2.el also fixes it.

Cheers,
Luís





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#33828: 26.1; Unbound defvar across compilation units
  2018-12-21 12:02 bug#33828: 26.1; Unbound defvar across compilation units Luís Oliveira
@ 2018-12-21 13:50 ` Luís Oliveira
  2018-12-21 20:02 ` Eli Zaretskii
  1 sibling, 0 replies; 7+ messages in thread
From: Luís Oliveira @ 2018-12-21 13:50 UTC (permalink / raw)
  To: 33828; +Cc: João Távora

On Fri, Dec 21, 2018 at 12:02 PM Luís Oliveira <luismbo@gmail.com> wrote:
> I think I've come across a bug.

But it seems to be documented behaviour:

    Note that specifying a value, even nil, marks the variable as
special permanently. Whereas if value is omitted then the variable is
only marked special locally (i.e. within the current lexical scope, or
file if at the top-level). This can be useful for suppressing byte
compilation warnings, see Compiler Errors.
    (https://www.gnu.org/software/emacs/manual/html_node/elisp/Defining-Variables.html)

Please disregard this bug report. :-)

Luís





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#33828: 26.1; Unbound defvar across compilation units
  2018-12-21 12:02 bug#33828: 26.1; Unbound defvar across compilation units Luís Oliveira
  2018-12-21 13:50 ` Luís Oliveira
@ 2018-12-21 20:02 ` Eli Zaretskii
  2018-12-22  2:45   ` João Távora
  1 sibling, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2018-12-21 20:02 UTC (permalink / raw)
  To: Luís Oliveira; +Cc: joaotavora, 33828

> From: Luís Oliveira <luismbo@gmail.com>
> Date: Fri, 21 Dec 2018 12:02:55 +0000
> Cc: João Távora <joaotavora@gmail.com>
> 
> I think I've come across a bug.

Doesn't look like a bug to me.

>     (defun f2-foo ()
>       (let ((my-special 123))
>         (f2-bar)))
> 
>     (defun f2-bar ()
>       my-special)
> 
>     (print (f2-bar))
> 
> 
> 
>     $ emacs -Q -L . -f batch-byte-compile f2.el
> 
>     In toplevel form:
>     f2.el:5:1:Warning: Unused lexical variable `my-special'

That's because you do nothing with the value of f2-bar.

>     In f2-bar:
>     f2.el:10:3:Warning: reference to free variable `my-special'
> 
> 
> Also:
> 
>     $ emacs -Q -L . -batch -l f2.el
>     Symbol's value as variable is void: my-special

You need to use defvar in the same file.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#33828: 26.1; Unbound defvar across compilation units
  2018-12-21 20:02 ` Eli Zaretskii
@ 2018-12-22  2:45   ` João Távora
  2018-12-22  7:43     ` Eli Zaretskii
  2018-12-22 22:40     ` Philipp Stephani
  0 siblings, 2 replies; 7+ messages in thread
From: João Távora @ 2018-12-22  2:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Luís Oliveira, 33828

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Luís Oliveira <luismbo@gmail.com>
>> Date: Fri, 21 Dec 2018 12:02:55 +0000
>> Cc: João Távora <joaotavora@gmail.com>
>> 
>> I think I've come across a bug.
>
> Doesn't look like a bug to me.

Indeed, it's the behaviour described in the Emacs manual, but the
motivation is questionable: it says it's useful for shooshing the
byte-compiler's warnings.  Aren't there better alternatives to do this
instead of imposing this seeming inconsistency?

>>     (defun f2-foo ()
>>       (let ((my-special 123))
>>         (f2-bar)))
>> 
>>     (defun f2-bar ()
>>       my-special)
>> 
>>     (print (f2-bar))
>> 
>> 
>> 
>>     $ emacs -Q -L . -f batch-byte-compile f2.el
>> 
>>     In toplevel form:
>>     f2.el:5:1:Warning: Unused lexical variable `my-special'
>
> That's because you do nothing with the value of f2-bar.

f2-bar is a function, and it is called.  Did you mean 'my-special'?  It
is used as well, in f2-bar.

>> Also:
>> 
>>     $ emacs -Q -L . -batch -l f2.el
>>     Symbol's value as variable is void: my-special
>
> You need to use defvar in the same file.

Or alternatively, use the variable in a different file but ensure the
defvar was declared with an initial value.  When you do that, it produces
the expected behaviour for someone who is accustomed to other Lisps
lexical and dynamic binding, such as Common Lisp.  In other words, it's
the edge case defvar-in-different-file-with-no-initial-binding that
we're questioning here.  The presence of the initial binding seems to
matter, even though its value is useless.

João







^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#33828: 26.1; Unbound defvar across compilation units
  2018-12-22  2:45   ` João Távora
@ 2018-12-22  7:43     ` Eli Zaretskii
  2018-12-22 22:40     ` Philipp Stephani
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2018-12-22  7:43 UTC (permalink / raw)
  To: João Távora; +Cc: luismbo, 33828

> From: João Távora <joaotavora@gmail.com>
> Cc: Luís Oliveira <luismbo@gmail.com>,
>   33828@debbugs.gnu.org
> Date: Sat, 22 Dec 2018 02:45:32 +0000
> 
> >>     (defun f2-foo ()
> >>       (let ((my-special 123))
> >>         (f2-bar)))
> >> 
> >>     (defun f2-bar ()
> >>       my-special)
> >> 
> >>     (print (f2-bar))
> >> 
> >> 
> >> 
> >>     $ emacs -Q -L . -f batch-byte-compile f2.el
> >> 
> >>     In toplevel form:
> >>     f2.el:5:1:Warning: Unused lexical variable `my-special'
> >
> > That's because you do nothing with the value of f2-bar.
> 
> f2-bar is a function, and it is called.  Did you mean 'my-special'?  It
> is used as well, in f2-bar.

I meant the value returned by f2-bar in f2-foo.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#33828: 26.1; Unbound defvar across compilation units
  2018-12-22  2:45   ` João Távora
  2018-12-22  7:43     ` Eli Zaretskii
@ 2018-12-22 22:40     ` Philipp Stephani
  2018-12-23  1:16       ` João Távora
  1 sibling, 1 reply; 7+ messages in thread
From: Philipp Stephani @ 2018-12-22 22:40 UTC (permalink / raw)
  To: João Távora; +Cc: luismbo, 33828

Am Sa., 22. Dez. 2018 um 03:46 Uhr schrieb João Távora <joaotavora@gmail.com>:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Luís Oliveira <luismbo@gmail.com>
> >> Date: Fri, 21 Dec 2018 12:02:55 +0000
> >> Cc: João Távora <joaotavora@gmail.com>
> >>
> >> I think I've come across a bug.
> >
> > Doesn't look like a bug to me.
>
> Indeed, it's the behaviour described in the Emacs manual, but the
> motivation is questionable: it says it's useful for shooshing the
> byte-compiler's warnings.  Aren't there better alternatives to do this
> instead of imposing this seeming inconsistency?

The better alternative is to explicitly `require' the library that
defines the variable.
I see the one-argument `defvar' as the variable equivalent to
`declare-function' - it announces that a variable exists without
defining it. (Maybe there should be a `declare-variable' macro to
mirror `declare-function'.) As such, its use should be exceptional;
most libraries should make sure to not have cyclic dependencies and
use plain `require'.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#33828: 26.1; Unbound defvar across compilation units
  2018-12-22 22:40     ` Philipp Stephani
@ 2018-12-23  1:16       ` João Távora
  0 siblings, 0 replies; 7+ messages in thread
From: João Távora @ 2018-12-23  1:16 UTC (permalink / raw)
  To: Philipp Stephani; +Cc: Luís Borges de Oliveira, 33828

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

On Sat, Dec 22, 2018 at 10:41 PM Philipp Stephani <p.stephani2@gmail.com>
wrote:

> Am Sa., 22. Dez. 2018 um 03:46 Uhr schrieb João Távora <
> joaotavora@gmail.com>:
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> From: Luís Oliveira <luismbo@gmail.com>
> > >> Date: Fri, 21 Dec 2018 12:02:55 +0000
> > >> Cc: João Távora <joaotavora@gmail.com>
> > >>
> > >> I think I've come across a bug.
> > >
> > > Doesn't look like a bug to me.
> >
> > Indeed, it's the behaviour described in the Emacs manual, but the
> > motivation is questionable: it says it's useful for shooshing the
> > byte-compiler's warnings.  Aren't there better alternatives to do this
> > instead of imposing this seeming inconsistency?
>
> The better alternative is to explicitly `require' the library that
> defines the variable.
> I see the one-argument `defvar' as the variable equivalent to
> `declare-function' - it announces that a variable exists without
> defining it. (Maybe there should be a `declare-variable' macro to
> mirror `declare-function'.) As such, its use should be exceptional;
> most libraries should make sure to not have cyclic dependencies and
> use plain `require'.
>

I think in Luís original report there is a `require' of the library where
the variable is declared before using it. Unfortunately it only works
when it is declared with an initial value.

João

[-- Attachment #2: Type: text/html, Size: 2198 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-12-23  1:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-21 12:02 bug#33828: 26.1; Unbound defvar across compilation units Luís Oliveira
2018-12-21 13:50 ` Luís Oliveira
2018-12-21 20:02 ` Eli Zaretskii
2018-12-22  2:45   ` João Távora
2018-12-22  7:43     ` Eli Zaretskii
2018-12-22 22:40     ` Philipp Stephani
2018-12-23  1:16       ` João Távora

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).