From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Mon, 06 Oct 2014 20:10:21 -0400 Message-ID: <877g0ceo42.fsf@netris.org> References: <54193A70.9020901@member.fsf.org> <83iokato6x.fsf@gnu.org> <87wq8pwjen.fsf@uwakimon.sk.tsukuba.ac.jp> <837g0ptnlj.fsf@gnu.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412640675 26528 80.91.229.3 (7 Oct 2014 00:11:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2014 00:11:15 +0000 (UTC) Cc: dak@gnu.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org, stephen@xemacs.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 07 02:11:07 2014 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 1XbIMr-0005dr-Ls for ged-emacs-devel@m.gmane.org; Tue, 07 Oct 2014 02:11:05 +0200 Original-Received: from localhost ([::1]:55420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbIMr-0003od-6B for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 20:11:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbIMi-0003oN-W5 for emacs-devel@gnu.org; Mon, 06 Oct 2014 20:11:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbIMd-0007u4-2n for emacs-devel@gnu.org; Mon, 06 Oct 2014 20:10:56 -0400 Original-Received: from world.peace.net ([96.39.62.75]:57025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbIMP-0007ri-Ko; Mon, 06 Oct 2014 20:10:37 -0400 Original-Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23] helo=jojen) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XbIM8-0007QN-Kn; Mon, 06 Oct 2014 20:10:20 -0400 In-Reply-To: (Richard Stallman's message of "Mon, 06 Oct 2014 15:17:15 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:175057 Archived-At: Richard Stallman writes: > However, I would argue that even in Emacs, string<->bytevector > conversions should be strict by default, > > What is a "bytevector"? Bytevectors are packed arrays of unsigned integers < 256. It is the standard Scheme data type for performing binary I/O. String operations deliberately do not work on them. In contrast, strings are packed arrays of characters, which in Scheme are not integers but rather an abstract type representing Unicode code points. > How would it relate into Emacs? Maybe your suggestion is a good one. Implicit string<->bytevector conversions are needed almost every time a string is passed to/from the C world, since most C APIs are based on bytes not Unicode characters. This includes I/O, command-line arguments and environment variables (whether reading the ones given to us or passing new ones down to subprocesses), POSIX file names, interfacing with most C libraries, etc. My suggestion is that these implicit conversions should be strict by default. IMO, only in specific cases (most notably when editing a file) should invalid byte sequences by accepted, produced, or propagated. The reasons are (1) to protect internal subsystems (subprocesses, C functions linked with Guile, etc) from invalid input such as overlong encodings, and (2) to catch errors early rather than silently producing garbage in the face of programming errors. However, it is of course up to the Emacs community to decide when conversions should be strict. Guile can provide both modes of operation. Mark