Re: master 48ac40e60e: ; Fix last change.

[Stefan Monnier]

>> It's not a very specific API.  It's a kind of "abstract super class", so
>> in my book it should be defined not by enumerating its current
>> subclasses but by giving a meaningful way to decide whether a given
>> class should be a subclass or not.
> Sorry, I reject the idea that abstract classes cannot be usefully
> documented in concrete terms.  At least there's no excuse for not
> trying.

I'm not opposed to doing it, but I feel that it's not sufficient because
it doesn't say why that abstract class exists (i.e. what it is that
makes it meaningful to group those different classes under that abstract
class).

To me it's akin to describing a particular image by listing the pixels
it contains and their color but without saying what the
image represents.  We may be able to use our brain to figure out what
the image represents, but it's not always obvious that everyone will end
up with the same understanding.

How 'bout the patch below?


        Stefan


diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
index ddf7cff6c2e..983dfe2ec59 100644
--- a/doc/lispref/functions.texi
+++ b/doc/lispref/functions.texi
@@ -219,10 +219,12 @@ What Is a Function
 
 @defun compiled-function-p object
 This function returns @code{t} if @var{object} is a function object
-that was either built-in (a.k.a.@: ``primitive'', @pxref{What Is a
-Function}), or byte-compiled (@pxref{Byte Compilation}), or
-natively-compiled (@pxref{Native Compilation}), or a function loaded
-from a dynamic module (@pxref{Dynamic Modules}).
+that is not in the form of ELisp source code but something like
+machine code or byte code instead.  More specifically it returns
+@code{t} if the function is built-in (a.k.a.@: ``primitive'',
+@pxref{What Is a Function}), or byte-compiled (@pxref{Byte
+Compilation}), or natively-compiled (@pxref{Native Compilation}), or
+a function loaded from a dynamic module (@pxref{Dynamic Modules}).
 @end defun
 
 @defun subr-arity subr