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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67455 <at> debbugs.gnu.org
Subject: bug#67455: Record source position, etc., in doc strings, and use this in *Help* and backtraces.
Date: Fri, 15 Dec 2023 18:12:42 -0500

> The problem that has thrown me is the use of the doc string in oclosures
> for other purposes.  For example, in position 2 of a lambda form,
> appears something like
>
>     (:documentation 'oclosure-accessor)

Hmm...

> ..  My current code is expecting, on encountering (:documentation ...),
> for the cadr to be a string,

`:documentation` is supposed to be followed by an expression (whose
evaluation should usually return a string, although indeed we abuse it
in the case of OClosures to return a symbol instead).

Regardless of OClosures, the `cadr` of a `:documentation` will very
rarely be a mere string since you don't need `:documentation` when the
docstring can be written as a literal.

> onto which it can add a concat form which
> will prefix the position information.

For the non-OClosure case you should be able to use the equivalent of:

    (:documentation
     (concat <YOURINFOHERE> <THEORIGINALEXPRESSIONHERE>))

is that what you mean?

> A solution to this problem would be to move the above symbol to element
> 2 of the list, something like
>
>     (:documentation nil 'oclosure-accessor)

Here you're talking about the source code, right?
I think the question is rather what representation to use in the values:
OClosures store their type name (symbol) in the slot that normally holds
the docstring, so I think the best short term answer is to say that
OClosures aren't supported by your new feature.

OClosures are a mix of functions and structs, so while it would be
nice to make them enjoy your new feature, I think it's perfectly OK
to say that in this respect they're more like structs than like
functions.
Also they come with more introspection features than normal
functions, so it's usually easier to figure out where they come from
(you can find their type, and then look for the `oclosure-lambda`s
which built OClosures of this type.  For most OClosure types, there's
only one such lambda anyway).

> , so that my new code could place its information in the now vacant
> position 1, giving something like
>
>     (:documentation ";POS\36\0\0\0 [ .... ]\n" 'oclosure-accessor)
>
> ..  What do you think of this idea, and have you any better ideas for a
> solution to the problem?

If it works it might be a good option.  I don't know how this turns into
when we build the corresponding bytecode object, so it's hard to judge.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.