RE: [Emacs-diffs] trunk r113747: lisp/frameset.el: Convert `frameset' to vector and add new slots.

[Drew Adams]

> >> I know we have some offenders, but please try to stick to "foo-p returns
> >> a boolean".
> > Why?  It's a CL-style predicate, which returns a "generalized boolean"
> > (either nil, or anything else).  What is the harm in returning the
> > version?
> 
> I don't really care that it doesn't always return t as non-nil value.
> But its non-nil value should be treated by its docstring (and by
> callers) as a boolean equivalent to t.  Otherwise it's not just
> a "predicate" but an accessor.

Are you OK with it always returning the version numbar as non-nil value?
That's the question, no?

You don't seriously insist that it sometimes return some other non-nil
value (a strawberry tart, for example) for a frameset argument, do you?

Anytime the type predicate returns a true value - any true value, the
argument must be a frameset.  Sure.  But that does not impose any
condition on the particular true value the predicate must return.  Any
non-nil value will do, including the version number.  A version number
is as true as any other non-nil value in Emacs Lisp.  Don't believe it?
Ask `if', `cond', `and', `or',...

I'm with Juanma on this one.  The function is a type predicate AND it
provides the version number for an object of the type.  You can use it
as a predicate (it is one).  And if the object is a frameset then you
can use it to get the version.  100% of the time.

This is Emacs Lisp, not Scheme.  Since its early days Lisp has used
`nil' and `()' for both false and the empty list; and it has used 
everything else for true.  Some have disagreed with this conflation [*],
but it is the case for Emacs Lisp, just as it is for most other Lisps.

I do agree that the doc string needs to make it clear that `frameset-p'
returns non-nil for a frameset and nil for something that is not a
frameset.  But that is already the case, AFAICT.

If you want it to also explicitly point out that a version number is
always non-nil then I don't see the point in that.  But that is the only
information about the Boolean value and the type predicate that is not
explicitly present already.

> >> Also, this doesn't just test whether it's a frameset or not (which is
> >> what one expects from "frameset-p") but it does some sanity checks
> >> as well, something I'd call maybe "frameset-valid-p".
> > It needs to be called `frameset-p' for cl-typep to work.
> 
> You can use the built-in frameset-p (and then remove the :named
> and :type as well, so that the tag becomes internal/hidden, which
> I also find cleaner)).

The built-in `frameset-p' would not test framesetness!  Not as Juanma
wants to define it.  It would test only for a built-in, minimal
defstruct type definition.

`defstruct' was not designed to be used in only that way.  It explicitly
provides for defining a type predicate that does something different
from a default, auto-generated type predicate.  And thank goodness, too.

If this is done the way Juanma has done it then a nil return value by
`frameset-p' says that the object in question is not a frameset even
if it has tag `frameset' and its slots fit the defining defstruct, etc.
It has to be more than that to be a frameset.  What more?  That which is
coded in `frameset-p' and described in the doc string.

There is nothing wrong with such a tighter-than-default type definition.

You can add, as part of the definition of a type `foo', a condition that
an object is of type `foo' only if it is green, can sing bass notes, and
today is Thursday in UTC time, if you want.  Imagine that!  A viewpoint
that says that the same object (as judged by other predicates, at least)
is of type `foo' on Thursday and not of type `foo' on Friday!  Wrt
fooness, it is not the same object on Thursday as on Friday...

As long as the doc clearly supports the frameset defstruct definition,
describing what an object must be like to be a frameset, there is
nothing wrong with having a more-complex-than-default type definition.

So the question then is, do you not feel that the doc describes the
type definition adequately?

> > If you're suggesting that I split the current frameset-p into a
> > strict-boolean-returning frameset-p and a more thorough
> > frameset-valid-p, I can do that, but, what is the gain?
> 
> That's it's more idiomatic?

I don't think so.  What's the proof of that?

[*] See section 3.1: http://www.dreamsongs.com/NewFiles/HOPL2-Uncut.pdf