From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: make-vector documentation is wrong Date: Thu, 14 May 2020 19:59:44 -0700 Message-ID: <443d57ff-d040-078e-8ad3-94f0c3458478@dancol.org> References: <0430a770-2bb8-2d46-9b28-420c8a6e0a24@dancol.org> <5bcc3508-9d65-c5b4-255e-898f8e1dc3c1@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="4296"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Emacs developers To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 15 05:02:06 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZQbs-0000xj-Sl for ged-emacs-devel@m.gmane-mx.org; Fri, 15 May 2020 05:02:04 +0200 Original-Received: from localhost ([::1]:53512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZQbr-0007Hc-Pp for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 23:02:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZQZh-0005uu-2S for emacs-devel@gnu.org; Thu, 14 May 2020 22:59:49 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36582) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZQZf-0007gl-8Q for emacs-devel@gnu.org; Thu, 14 May 2020 22:59:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KMfMdMQf2MjgWt1XnppZc9RrWGvibUUCnWcqJ/0hgSQ=; b=QEe1EKvAPvO/F/qU9NggeB4HxO kdElAb47itVG9P+lnTPi3yZzpttaL6TKjAlBsAINJFmFBeNwD/H1CqZIR/eQb5L34kW9ViFSe4u7z 3w0O6Q3kVj5ziGjV+BEwI077kRKTEhUE7k/mD6Lo8R3NjgaYqv44BeA7lg+lUawoO+o4vdukb+NT/ giV9phB3Z/54wkLN0ONi1y+jCRVMhmUFWp1d2r5HlhMGFyGRGApP5U+OefjVnuwPRJDyN2GaQQ8gS SxO07YOEXPTdOj0hNbPPNfBaueUYnKYJ/cLGfNpRo6L7HAXkY2AU0y2sNZKViVQFYp0hCeKB9kdIx yyWf0AVQ==; Original-Received: from [2604:4080:1321:9a00:519a:d934:f5c4:db2e] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jZQZd-00073h-6D; Thu, 14 May 2020 19:59:45 -0700 In-Reply-To: <5bcc3508-9d65-c5b4-255e-898f8e1dc3c1@cs.ucla.edu> Content-Language: en-US Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fedf:adf3; envelope-from=dancol@dancol.org; helo=dancol.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250312 Archived-At: On 5/14/20 7:46 PM, Paul Eggert wrote: > On 5/14/20 6:36 PM, Daniel Colascione wrote: >> We should fix either the docstring or the behavior >> of make-vector, and the latter seems better to me because it reduces the number >> of special cases in the system. > > That depends on how one counts special cases. > > (make-string 0 0), (make-list 0 0), (vector), and (list) all have the property > that (make-vector 0 0) does - that is, each call returns the same empty object > each time. I imagine that make-vector was implemented to be consistent with the > other functions - at least, this behavior appears to be a conscious decision > rather than accidental. So it may make sense to change these functions' > documentation instead of their implementation's longstanding behavior. Sure. We should make all of these things consistent. I'm not yet convinced that the special treatment of the zero-length object of any of these types actually helps though. Do we have any evidence that it does?