From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] A few cl-lib tests Date: Sat, 21 Feb 2015 15:18:46 -0500 Message-ID: References: <54E7C046.2050908@cumego.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424550013 23356 80.91.229.3 (21 Feb 2015 20:20:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Feb 2015 20:20:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?Przemys=C5=82aw?= Wojnowski Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 21 21:20:07 2015 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 1YPGX0-0004ds-JN for ged-emacs-devel@m.gmane.org; Sat, 21 Feb 2015 21:20:06 +0100 Original-Received: from localhost ([::1]:37290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPGWu-0005MO-Sc for ged-emacs-devel@m.gmane.org; Sat, 21 Feb 2015 15:20:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPGWI-0004tX-Hu for emacs-devel@gnu.org; Sat, 21 Feb 2015 15:19:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPGWD-0008Mu-IR for emacs-devel@gnu.org; Sat, 21 Feb 2015 15:19:22 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:30283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPGWD-0008Mp-F4 for emacs-devel@gnu.org; Sat, 21 Feb 2015 15:19:17 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsTAPOG1lTO+LI//2dsb2JhbABbgwaDX4VTwGUEAgKBDUQBAQEBAQF8hA0BBAFWIwULCzQSFBgNJIg4CM4jAQEBAQYBAQEBHo94B4QqBYonn0uBRSKEDCCCcwEBAQ X-IPAS-Result: ArsTAPOG1lTO+LI//2dsb2JhbABbgwaDX4VTwGUEAgKBDUQBAQEBAQF8hA0BBAFWIwULCzQSFBgNJIg4CM4jAQEBAQYBAQEBHo94B4QqBYonn0uBRSKEDCCCcwEBAQ X-IronPort-AV: E=Sophos;i="5.09,536,1418101200"; d="scan'208";a="111108410" Original-Received: from 206-248-178-63.dsl.teksavvy.com (HELO pastel.home) ([206.248.178.63]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2015 15:19:16 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E935D1462; Sat, 21 Feb 2015 15:18:46 -0500 (EST) In-Reply-To: <54E7C046.2050908@cumego.com> (=?utf-8?Q?=22Przemys=C5=82aw?= Wojnowski"'s message of "Sat, 21 Feb 2015 00:16:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:183362 Archived-At: > 1. What should be level of compatibility with Common Lisp? > Should it be as strict as possible (e.g. missing keywords, > functions vs macros)? We mostly try to be faithful to the Common Lisp spec, but we don't try super hard, because the purpose of cl-lib is not to let you run Common-Lisp code, but to provide CL-style functionality to Elisp. So, if there's no good reason to be incompatible, we try to be. But if performance would unduly suffer, or if it's "too much work" we sometimes stick to something "close enough". To take a recent example: in the new cl-generic.el code, I provided a way to change the method-combination, but in an incompatible way, because I consider that define-method-combination sucks. > Usually it is a file named in the same way as the tested > lib with added postfix "tests". That's right. > Is it ok to move incorrectly placed tests to correct files? Yes, of course. There might be disagreement about what is the correct place, tho ;-) > +(ert-deftest cl-lib-test-nth-value () > + (should (= 1 (cl-nth-value 0 '(1)))) > + (should (null (cl-nth-value 1 '(1)))) > + (should-error (cl-nth-value 0.0 '(1)) :type 'wrong-type-argument) > + (should-error (cl-nth-value 0 "only lists") :type 'wrong-type-argument)) IIUC, this tests the current broken approximation of "multiple values", so those tests would likely fail if we were to try and improve the implementation of multiple values. So I think these tests are wrong. They should look more like: (ert-deftest cl-lib-test-nth-value () (should (= 1 (cl-nth-value 0 (values 1)))) (should (null (cl-nth-value 1 (values 1)))) (should-error (cl-nth-value 0.0 (values 1)) :type 'wrong-type-argument)) -- Stefan