Why looking-at-p works?

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?

[Marcin Borkowski]

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

How about this patch?

On 2018-03-07, at 10:09, Marcin Borkowski <mbork@mbork.pl> wrote:

> 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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Reword-docs-of-let-and-let.patch --]
[-- Type: text/x-patch, Size: 2541 bytes --]

From dfd9978d839eccf744835e2e1daed9e140800214 Mon Sep 17 00:00:00 2001
From: Marcin Borkowski <mbork@mbork.pl>
Date: Wed, 7 Mar 2018 14:03:57 +0100
Subject: [PATCH] Reword docs of let and let*

Make it slightly more prominent that local bindings are destroyed in
case of an error within let's body.
---
 doc/lispref/variables.texi | 4 ++--
 src/eval.c                 | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
index e025d3fd10..49eba3816e 100644
--- a/doc/lispref/variables.texi
+++ b/doc/lispref/variables.texi
@@ -155,7 +155,7 @@ Local Variables
 
   Global variables have values that last until explicitly superseded
 with new values.  Sometimes it is useful to give a variable a
-@dfn{local value}---a value that takes effect only within a certain
+@dfn{local value}---a value that is in effect only within a certain
 part of a Lisp program.  When a variable has a local value, we say
 that it is @dfn{locally bound} to that value, and that it is a
 @dfn{local variable}.
@@ -165,7 +165,7 @@ Local Variables
 function call; these local bindings take effect within the body of the
 function.  To take another example, the @code{let} special form
 explicitly establishes local bindings for specific variables, which
-take effect within the body of the @code{let} form.
+are in effect only within the body of the @code{let} form.
 
   We also speak of the @dfn{global binding}, which is where
 (conceptually) the global value is kept.
diff --git a/src/eval.c b/src/eval.c
index 08a73b1e4a..bc08f0d084 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -843,7 +843,7 @@ DEFUN ("internal-make-var-non-special", Fmake_var_non_special,
 
 \f
 DEFUN ("let*", FletX, SletX, 1, UNEVALLED, 0,
-       doc: /* Bind variables according to VARLIST then eval BODY.
+       doc: /* Bind local variables according to VARLIST then eval BODY.
 The value of the last form in BODY is returned.
 Each element of VARLIST is a symbol (which is bound to nil)
 or a list (SYMBOL VALUEFORM) (which binds SYMBOL to the value of VALUEFORM).
@@ -902,7 +902,7 @@ usage: (let* VARLIST BODY...)  */)
 }
 
 DEFUN ("let", Flet, Slet, 1, UNEVALLED, 0,
-       doc: /* Bind variables according to VARLIST then eval BODY.
+       doc: /* Bind local variables according to VARLIST then eval BODY.
 The value of the last form in BODY is returned.
 Each element of VARLIST is a symbol (which is bound to nil)
 or a list (SYMBOL VALUEFORM) (which binds SYMBOL to the value of VALUEFORM).
-- 
2.16.2

Re: Why looking-at-p works?

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Wed, 07 Mar 2018 14:06:29 +0100
> Cc: John Mastro <john.b.mastro@gmail.com>, Drew Adams <drew.adams@oracle.com>
> 
> How about this patch?

Thanks, I fixed this with a slightly different text, and I see no need
to change the doc string in eval.c.

Re: Why looking-at-p works?

[Marcin Borkowski]

On 2018-03-07, at 20:53, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Wed, 07 Mar 2018 14:06:29 +0100
>> Cc: John Mastro <john.b.mastro@gmail.com>, Drew Adams <drew.adams@oracle.com>
>> 
>> How about this patch?
>
> Thanks, I fixed this with a slightly different text, and I see no need
> to change the doc string in eval.c.

Out of curiosity, where can I see your changes?

-- 
Marcin Borkowski
http://mbork.pl

Re: Why looking-at-p works?

[Eli Zaretskii]

On March 8, 2018 6:20:17 AM GMT+02:00, Marcin Borkowski <mbork@mbork.pl> wrote:
> 
> On 2018-03-07, at 20:53, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Marcin Borkowski <mbork@mbork.pl>
> >> Date: Wed, 07 Mar 2018 14:06:29 +0100
> >> Cc: John Mastro <john.b.mastro@gmail.com>, Drew Adams
> <drew.adams@oracle.com>
> >> 
> >> How about this patch?
> >
> > Thanks, I fixed this with a slightly different text, and I see no
> need
> > to change the doc string in eval.c.
> 
> Out of curiosity, where can I see your changes?

On the release branch.

Re: Why looking-at-p works?

[Marcin Borkowski]

On 2018-03-08, at 05:40, Eli Zaretskii <eliz@gnu.org> wrote:

> On March 8, 2018 6:20:17 AM GMT+02:00, Marcin Borkowski <mbork@mbork.pl> wrote:
>> 
>> On 2018-03-07, at 20:53, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> >> From: Marcin Borkowski <mbork@mbork.pl>
>> >> Date: Wed, 07 Mar 2018 14:06:29 +0100
>> >> Cc: John Mastro <john.b.mastro@gmail.com>, Drew Adams
>> <drew.adams@oracle.com>
>> >> 
>> >> How about this patch?
>> >
>> > Thanks, I fixed this with a slightly different text, and I see no
>> need
>> > to change the doc string in eval.c.
>> 
>> Out of curiosity, where can I see your changes?
>
> On the release branch.

Thanks.

-- 
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

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-----