bug#11460: 24.1.50; doc string of `assert'

bug#11460: 24.1.50; doc string of `assert'

[Drew Adams]

"Second arg SHOW-ARGS means to include arguments of FORM in message."
 
How so?  Which values of SHOW-ARGS mean that?

And what on earth are the "arguments" of FORM?  FORM is presumably a sexp, which
is evaluated and returns nil or non-nil.  A sexp does not have "arguments".

It's not at all clear what you mean here.

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-05-06 on MARVIN
Bzr revision: 108144 cyd@gnu.org-20120507053738-5ovifsb71cmamn2f
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

bug#11460: 24.1.50; doc string of `assert'

[Drew Adams]

ping

bug#11460: 24.1.50; doc string of `assert'

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> "Second arg SHOW-ARGS means to include arguments of FORM in message."
>
> How so?  Which values of SHOW-ARGS mean that?
>
> And what on earth are the "arguments" of FORM?  FORM is presumably a sexp, which
> is evaluated and returns nil or non-nil.  A sexp does not have "arguments".
>
> It's not at all clear what you mean here.

Looking at the code, I'm still not sure what the meaning here is.

       (let ((sargs (and show-args
                         (delq nil (mapcar (lambda (x)
                                             (unless (macroexp-const-p x)
                                               x))
                                           (cdr form))))))

So...  if the elements in the rest of FORM evaluate to the same value,
they're included in the error output, but if not, not?  Uhm...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#11460: 24.1.50; doc string of `assert'

[Stefan Monnier]

> Looking at the code, I'm still not sure what the meaning here is.

>        (let ((sargs (and show-args
>                          (delq nil (mapcar (lambda (x)
>                                              (unless (macroexp-const-p x)
>                                                x))
>                                            (cdr form))))))

> So...  if the elements in the rest of FORM evaluate to the same value,
> they're included in the error output, but if not, not?  Uhm...

FWIW, this part of `cl-assert' is not only poorly documented, but it's
poorly designed.  And it doesn't have the excuse that it's inherited
from Common Lisp.
So I'd rather not document that mis-feature in any more detail.


        Stefan

bug#11460: 24.1.50; doc string of `assert'

[Drew Adams]

> FWIW, this part of `cl-assert' is not only poorly documented, but
> it's poorly designed.  And it doesn't have the excuse that it's
> inherited from Common Lisp.
>
> So I'd rather not document that mis-feature in any more detail.

In that case, my request would be that the entire bug be recorded
and kept open for future fixing (e.g., todo list or whatever):
design + implementation + doc.

IOW, let's not use the fact that the design, in addition to the
doc, is faulty as an excuse to just drop this.  If it needs
fixing and you cannot or do not want to tackle that now, then
it should be kept open for fixing later.

bug#11460: 24.1.50; doc string of `assert'

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, this part of `cl-assert' is not only poorly documented, but it's
> poorly designed.  And it doesn't have the excuse that it's inherited
> from Common Lisp.
> So I'd rather not document that mis-feature in any more detail.

Ok; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#11460: 24.1.50; doc string of `assert'

[Drew Adams]

> > FWIW, this part of `cl-assert' is not only poorly documented, but
> > it's poorly designed.  And it doesn't have the excuse that it's
> > inherited from Common Lisp.
> > So I'd rather not document that mis-feature in any more detail.
> 
> Ok; closing.

That is a cop-out.  What has been uncovered is that instead of
a minor, doc bug, there is a major bug.

If you close this as being only the doc part, then you really
should open a new bug for the whole problem: design, implementation,
and doc.

C'mon folks.  It is not just about closing bugs.  It is about
recording problems that need fixing.  And hopefully, one day,
fixing them.

It is quite distressing to see the reaction of "Ok; closing",
if that is to be the only response.  A bug should be recorded
for this major problem, and left open until it is fixed.