From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [Emacs-diffs] trunk r113747: lisp/frameset.el: Convert `frameset' to vector and add new slots. Date: Wed, 7 Aug 2013 21:05:52 -0700 (PDT) Message-ID: <11ff0a6d-a7cf-4796-9c8f-27284910b1ae@default> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1375934775 9366 80.91.229.3 (8 Aug 2013 04:06:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Aug 2013 04:06:15 +0000 (UTC) Cc: Emacs developers To: Stefan Monnier , Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 08 06:06:16 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V7HUN-0005On-TE for ged-emacs-devel@m.gmane.org; Thu, 08 Aug 2013 06:06:16 +0200 Original-Received: from localhost ([::1]:42637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7HUN-0000Ud-Bi for ged-emacs-devel@m.gmane.org; Thu, 08 Aug 2013 00:06:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7HUD-0000UG-RU for emacs-devel@gnu.org; Thu, 08 Aug 2013 00:06:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7HU3-0007Mt-W2 for emacs-devel@gnu.org; Thu, 08 Aug 2013 00:06:05 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7HU3-0007Md-Pt for emacs-devel@gnu.org; Thu, 08 Aug 2013 00:05:55 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7845r9U008127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 04:05:53 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7845pfr027493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 04:05:52 GMT Original-Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7845pRE005469; Thu, 8 Aug 2013 04:05:51 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6668.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162482 Archived-At: > >> I know we have some offenders, but please try to stick to "foo-p retur= ns > >> 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? >=20 > 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=20 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. >=20 > 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? >=20 > 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