Re: Why looking-at-p works?

Re: Why looking-at-p works?

[Emanuel Berg]

Marcin Borkowski wrote:

> (defsubst looking-at-p (regexp) "\ Same as
> `looking-at' except this function does not
> change the match data." (let
> ((inhibit-changing-match-data t)) (looking-at
> regexp)))
>
> What happens is that if I make looking-at in
> the above code fail (e.g., by saying
> (looking-at-p 123)),
> inhibit-changing-match-data remains nil, even
> though there is no unwind-protect here.
> Why does it work like this?

Do you need dynamic scope for `let' to work
like that?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Why looking-at-p works?

[andlind]

On Tuesday, 6 March 2018 09:50:03 UTC+1, Emanuel Berg  wrote:
> Do you need dynamic scope for `let' to work
> like that?

It depends on if the variable has been declared using `defvar' or not.

If is has beed declared with `defvar' then `let' will behave in the same way -- it appears as though the global variable is temporary changed in the body and in functions called from the body. In fact, this has been the standard way change a global variable in elisp for many years, and I guess no one was prepared to change it.

On the other hand, if the variable hasn't been declared then a statically scoped program will create a true local variable that doesn't affect called functions, whereas a dynamically scoped program would create a variable that would hide variables with the same name in outer scopes. (Reservation: I haven't verified this myself.)

Personally, I think elisp took a wrong turn when they retrofitted statically scopes to elisp. It would have been better to introduce a new primitive, say `slet', to create a static binding, regardless if the variable was global or not.

    -- Anders

Ps. If you use the package `lisp-font-lock-extra', variables bound e.g. by `let' will be highlighted, and the package will highlight local and globally declared variables differently. This helps you to avoid accidentally overwriting generically named global variables like `features' and `mode-name'.

Re: Why looking-at-p works?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 15, 2018 at 01:34:36AM -0700, andlind@gmail.com wrote:

[...]

> Ps. If you use the package `lisp-font-lock-extra', variables bound e.g. by `let' will be highlighted, and the package will highlight local and globally declared variables differently. This helps you to avoid accidentally overwriting generically named global variables like `features' and `mode-name'.

Woah. Thanks for this one!

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr6nv8ACgkQBcgs9XrR2kbzCgCfQLfBGq4aJ4Ydvz5iKFmgR8rz
Vo8An1S45O8j+ZjEAJG0eXXRb0EsXrS6
=Qt7a
-----END PGP SIGNATURE-----

Why looking-at-p works?

[Marcin Borkowski]

Hi all,

(defsubst looking-at-p (regexp)
  "\
Same as `looking-at' except this function does not change the match data."
  (let ((inhibit-changing-match-data t))
    (looking-at regexp)))

What happens is that if I make looking-at in the above code fail (e.g.,
by saying (looking-at-p 123)), inhibit-changing-match-data remains nil,
even though there is no unwind-protect here.  Why does it work like
this?

TIA,

-- 
Marcin Borkowski
http://mbork.pl

Re: Why looking-at-p works?

[John Mastro]

Marcin Borkowski <mbork@mbork.pl> wrote:
> Hi all,
>
> (defsubst looking-at-p (regexp)
>   "\
> Same as `looking-at' except this function does not change the match data."
>   (let ((inhibit-changing-match-data t))
>     (looking-at regexp)))
>
> What happens is that if I make looking-at in the above code fail (e.g.,
> by saying (looking-at-p 123)), inhibit-changing-match-data remains nil,
> even though there is no unwind-protect here.  Why does it work like
> this?

If I understand your question correctly, it's nothing specific to
looking-at-p. Let-bindings are protected by a sort of implicit
unwind-protect so that they're always "un-done" upon exiting the scope,
even in case of non-local exits like an error. Otherwise errors could
leave global variables in unpredictable states.

        John

Re: Why looking-at-p works?

[Marcin Borkowski]

On 2018-03-06, at 19:53, John Mastro <john.b.mastro@gmail.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> wrote:
>> Hi all,
>>
>> (defsubst looking-at-p (regexp)
>>   "\
>> Same as `looking-at' except this function does not change the match data."
>>   (let ((inhibit-changing-match-data t))
>>     (looking-at regexp)))
>>
>> What happens is that if I make looking-at in the above code fail (e.g.,
>> by saying (looking-at-p 123)), inhibit-changing-match-data remains nil,
>> even though there is no unwind-protect here.  Why does it work like
>> this?
>
> If I understand your question correctly, it's nothing specific to
> looking-at-p. Let-bindings are protected by a sort of implicit
> unwind-protect so that they're always "un-done" upon exiting the scope,
> even in case of non-local exits like an error. Otherwise errors could
> leave global variables in unpredictable states.

Thanks, I suspected something like that.

Where is it documented?  I could find it neither in the Elisp Reference
nor in let's docstring.

TIA,

-- 
Marcin Borkowski
http://mbork.pl

RE: Why looking-at-p works?

[Drew Adams]

> Where is it documented?  I could find it neither in the Elisp
> Reference nor in let's docstring.

You might need to read a tiny bit between the lines, but this
(from (elisp) `Local Variables') pretty much suggests it:

  Sometimes it is useful to give a variable a "local value"-a
  value that takes effect only within a certain part of a Lisp
  program.

It might have said "is in effect" instead of "takes effect".

  To take another example, the 'let' special form explicitly
  establishes local bindings for specific variables, which
  take effect within the body of the 'let' form.

Again, "are in effect only" instead of "take effect".

(Consider suggesting a doc improvement for this point -
`M-x report-emacs-bug'.  And yes, probably the doc string
should mention "_local_ variable".)

Re: Why looking-at-p works?

[Marcin Borkowski]

On 2018-03-06, at 23:23, Drew Adams <drew.adams@oracle.com> wrote:

>> Where is it documented?  I could find it neither in the Elisp
>> Reference nor in let's docstring.
>
> You might need to read a tiny bit between the lines, but this
> (from (elisp) `Local Variables') pretty much suggests it:
>
>   Sometimes it is useful to give a variable a "local value"-a
>   value that takes effect only within a certain part of a Lisp
>   program.
>
> It might have said "is in effect" instead of "takes effect".
>
>   To take another example, the 'let' special form explicitly
>   establishes local bindings for specific variables, which
>   take effect within the body of the 'let' form.
>
> Again, "are in effect only" instead of "take effect".
>
> (Consider suggesting a doc improvement for this point -
> `M-x report-emacs-bug'.  And yes, probably the doc string
> should mention "_local_ variable".)

Thanks (to you, and also to Nick) for pointing me here.  I would not
call this very explicit;-).  I'll try to prepare a patch for the docs
today.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Why looking-at-p works?

[Nick Dokos]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2018-03-06, at 19:53, John Mastro <john.b.mastro@gmail.com> wrote:
>
>> Marcin Borkowski <mbork@mbork.pl> wrote:
>>> Hi all,
>>>
>>> (defsubst looking-at-p (regexp)
>>>   "\
>>> Same as `looking-at' except this function does not change the match data."
>>>   (let ((inhibit-changing-match-data t))
>>>     (looking-at regexp)))
>>>
>>> What happens is that if I make looking-at in the above code fail (e.g.,
>>> by saying (looking-at-p 123)), inhibit-changing-match-data remains nil,
>>> even though there is no unwind-protect here.  Why does it work like
>>> this?
>>
>> If I understand your question correctly, it's nothing specific to
>> looking-at-p. Let-bindings are protected by a sort of implicit
>> unwind-protect so that they're always "un-done" upon exiting the scope,
>> even in case of non-local exits like an error. Otherwise errors could
>> leave global variables in unpredictable states.
>
> Thanks, I suspected something like that.
>
> Where is it documented?  I could find it neither in the Elisp Reference
> nor in let's docstring.
>

(info "(elisp)Local variables")

-- 
Nick