bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.)

[Alan Mackenzie <acm@muc.de>]

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