From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bug#23750: 25.0.95; bug in url-retrieve or json.el Date: Wed, 28 Dec 2016 20:55:18 +0200 Message-ID: <83inq3vq7d.fsf@gnu.org> References: <6d0c8c2e-8428-2fdb-0d6e-899f7b9d7ffd@nifty.com> <8053af81-80e1-a24a-f649-8ffc86963ed5@nifty.com> <0cc7fab4-9a2c-6a8d-def7-36bd50317ca3@yandex.ru> <7f9a799f-de88-fd78-0cdc-dac0928f1503@nifty.com> <308bb78f-8be3-092d-d877-e129d340242b@nifty.com> <4dc615e7-ec73-60a5-426e-0d6986f15d76@yandex.ru> <0cb406fb-ffc4-a4ad-557a-2cacc99b8e75@nifty.com> <86ccb4af-5719-c017-26bb-fc06b4c904d2@yandex.ru> <83r35uxkr5.fsf@gnu.org> <4e12d4ad-cd6b-3087-5d7c-449d4c1886e2@yandex.ru> <83lgw1q9uu.fsf@gnu.org> <83eg1tq8is.fsf@gnu.org> <787e5206-53e0-752f-a339-4608d2f7ad39@yandex.ru> <8360n5q6j4.fsf@gnu.org> <8337i8rkbe.fsf@gnu.org> <83polcpzwk.fsf@gnu.org> <83lguzvr63.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1482951401 27714 195.159.176.226 (28 Dec 2016 18:56:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Dec 2016 18:56:41 +0000 (UTC) Cc: larsi@gnus.org, dgutov@yandex.ru, kentaro.nakazawa@nifty.com, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 28 19:56:37 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMJOm-0005eb-5R for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 19:56:28 +0100 Original-Received: from localhost ([::1]:60574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMJOr-000786-34 for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 13:56:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMJNz-00075g-PG for emacs-devel@gnu.org; Wed, 28 Dec 2016 13:55:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMJNw-0006cB-NC for emacs-devel@gnu.org; Wed, 28 Dec 2016 13:55:39 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMJNn-0006at-E4; Wed, 28 Dec 2016 13:55:27 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4253 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cMJNm-0007ZQ-Hh; Wed, 28 Dec 2016 13:55:27 -0500 In-reply-to: (message from Philipp Stephani on Wed, 28 Dec 2016 18:45:43 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:210926 Archived-At: > From: Philipp Stephani > Date: Wed, 28 Dec 2016 18:45:43 +0000 > Cc: larsi@gnus.org, emacs-devel@gnu.org, kentaro.nakazawa@nifty.com, > dgutov@yandex.ru > > > That has nothing to do with characters. A byte array is conceptually different from a character string. > > In Emacs, they are both implemented using very similar objects. > > Yes, that's why I said "conceptually different". The concepts may be the different, but the implementation > might still be the same. If the implementation is the same, then concepts are not very different to begin with, and the abstraction will sooner or later leak into applications. > Our experience is that we should keep use of unibyte strings in Lisp > application code to the absolute minimum, ideally zero. Once we > arrived at that conclusion, we've been living happily ever after. > This minor issue we are discussing here is certainly not worth > repeating past mistakes for which we paid plenty in sweat and blood. > > If you want unibyte strings to represent octet streams, then unibyte strings must be usable in application > code They are usable, but using them requires knowledge and proficiency that's unusual with many Lisp developers, and it also has some unpleasant pitfalls. > because octet streams are a concept that exists in reality, and applications must be able to support > them in some way. If you don't want unibyte strings, then you need to provide some different way to represent > octet streams. We use unibyte strings where we must, and otherwise prefer multibyte ones. In most cases the unibyte strings exist in Emacs internals, so that Lisp applications will not have to deal with them. This case is one of the few exceptions. If you are still unconvinced and think that we need some separate representation for byte arrays, consider this: when Emacs starts, it takes some time until it bootstraps itself enough to learn how to decode non-ASCII strings, such as file names. Until then, all file names are unibyte strings, and Emacs still must handle them correctly, because otherwise it would be impossible to build or start it in a directory that includes non-ASCII characters. This and other similar subtleties are the reason why using anything but a string for raw byte arrays is not a good idea, IMO and IME.