GNU bug report logs -
#67455
Record source position, etc., in doc strings, and use this in *Help* and backtraces.
Previous Next
Full log
View this message in rfc822 format
Hello, Stefan.
On Sat, Mar 30, 2024 at 22:22:52 -0400, Stefan Monnier wrote:
> >> We're still miscommunicating. You're talking about how your code is
> >> implemented, apparently, whereas I'm asking about what is the
> >> intended behavior.
> > I am still mystified by your failure to understand "currently being
> > defined", a phrase that to me could hardly be clearer.
> AFAIK, the definition itself happens inside `Fdefalias`. It's a very
> short amount of time during which none of your code is executed, so that
> can't be it.
The definition starts when the reader reads (defun foo ...). It ends
when that Fdefalias has been evaluated. Between those two events,
defining-symbol is bound to foo.
> The rest is the actual construction of the value/function object which
> will make up the definition. This construction is done piecemeal in
> various phases at potentially various different times, not all of them
> necessarily on the same machine.
Really? :-)
> Some of the code executed during the course of the construction of this
> object have nothing at all to do with that object, they just happen to
> be used by some code which participates in the construction of that
> object.
That's a bit too abstract. I can't see the potential problems that you
see, possibly because I've already solved them.
> So "currently" (i.e. referring to *time*) is very problematic because
> it's only loosely correlated to what you're interested in.
Again, I don't see these problems.
> >> It's like I'm asking what the C spec says and you're answering me by
> >> telling me how GCC works.
> > OK, let's try again. defining-symbol records the symbol currently being
> > defined. It's used to set the defining symbol and buffer offset fields
> > in the position structure in that symbol's doc string, and also in the
> > doc strings of contained lambda forms.
> I can try it again also if you want: to do it right, I think you want to
> store that information in `macroexpand-all-environment`.
That variable doesn't exist, yet.
> > Is my previous paragraph sufficiently clear? If so, can you envisage a
> > scenario where a symbol being defined would fail to get the two fields
> > correctly set in its doc string or a lambda form's doc string?
> Yes, for example I can imagine a lazy macroexpansion done to run some
> code during the eager macroexpansion could mistakenly think that it is
> part of the eagerly macroexpanded function (whereas it's only part of
> the code used during the construction of that function).
The critical thing here is the variable defining-symbol. I think you're
suggesting that its value could accidentally find its way into other
symbols' position structures. When are those other symbols getting
defined? Surely if a secondary defun, defmacro, defvar, ... happens
during the main defun, its defining symbol is that of the main defun?
> I'm sure there are other cases, by thinking of it makes my head hurt.
> Which is why I recommend you put that info into
> `macroexpand-all-environment` which is designed specifically for such
> purpose of "currently within the scope of something".
Well, m-a-e is defined too late. Even if it weren't, how would it solve
any of these problems you see? It's just swapping one dynamically bound
variable for another.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 1 year and 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.