From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] r7rs-wip branch: Add reader and print options to support R7RS bytevector syntax. Date: Tue, 20 Jun 2017 21:13:07 -0400 Message-ID: <871sqem9cs.fsf@netris.org> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1498007611 5360 195.159.176.226 (21 Jun 2017 01:13:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Jun 2017 01:13:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: Andy Wingo , guile-devel@gnu.org To: Freja Nordsiek Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jun 21 03:13:27 2017 Return-path: Envelope-to: guile-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 1dNUD1-00016y-11 for guile-devel@m.gmane.org; Wed, 21 Jun 2017 03:13:27 +0200 Original-Received: from localhost ([::1]:51301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dNUD6-0002u6-00 for guile-devel@m.gmane.org; Tue, 20 Jun 2017 21:13:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dNUD1-0002sW-31 for guile-devel@gnu.org; Tue, 20 Jun 2017 21:13:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dNUCw-00037y-3A for guile-devel@gnu.org; Tue, 20 Jun 2017 21:13:27 -0400 Original-Received: from world.peace.net ([50.252.239.5]:43443) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dNUCv-00036I-UH for guile-devel@gnu.org; Tue, 20 Jun 2017 21:13:22 -0400 Original-Received: from pool-72-93-34-106.bstnma.east.verizon.net ([72.93.34.106] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dNU2w-0006ZR-3u; Tue, 20 Jun 2017 21:03:02 -0400 In-Reply-To: (Freja Nordsiek's message of "Mon, 19 Jun 2017 01:28:04 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 50.252.239.5 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19223 Archived-At: Hi Freja, Freja Nordsiek writes: > Was fiddling around with using Chibi's R7RS test-suite in Guile and > found a major R7RS syntax feature currently missing from Guile. The > feature is R7RS bytevector notation, which uses the #u8 prefix like > SRFI-4 unsigned 8-bit integer vectors instead of the R6RS prefix #vu8. This is mostly not an issue, because in Guile, SRFI-4 vectors are actually just bytevectors. All of the bytevector operations work on them, and 'bytevector?' returns true for them. So, I expect that the overwhelming majority of R7RS code will work. To support this, Guile's bytevectors include an additional field called the "element type", which tells what kind of elements are in the bytevector, e.g. SCM_ARRAY_ELEMENT_TYPE_U8, SCM_ARRAY_ELEMENT_TYPE_F64, etc. See srfi-4.[ch] and bytevectors.[ch]. The only remaining issue is that, for some reason which I don't recall, we have distinct element types for plain bytevectors (as produced by our bytevector operations, and by reading #vu8(...)) and SRFI-4 unsigned 8-bit vectors (from reading #u8(...)), despite the fact that the elements are actually the same type. In the C code, they are: SCM_ARRAY_ELEMENT_TYPE_VU8 SCM_ARRAY_ELEMENT_TYPE_U8 This affects how bytevectors are printed, and it also affects equality testing on bytevectors: (bytevector=? #u8(1 2 3) #vu8(1 2 3)) => #f My preliminary attempt to mitigate this issue in 'r7rs-wip' was: commit 84aebcaecb78ac87b0039451becf9623e3ddcce4 Author: Mark H Weaver Date: Sun Jan 12 04:44:39 2014 -0500 bytevector=?: #vu8(1 2 3) is equal to #u8(1 2 3). * libguile/bytevectors.c (scm_bytevector_eq_p): Treat VU8 and U8 element types as equivalent. but I'm not sure it's the right solution. This alone will still result in R7RS code ending up with a mixture of U8 and VU8 bytevectors: the former for bytevector literals, and the latter as the results of other bytevector constructors. Perhaps the more obvious solution would be to completely eliminate the distinction between SRFI-4 u8 vectors and normal bytevectors by merging their element types, but there may be problems with that idea as well. Andy Wingo wrote the bytevector and SRFI-4 implementations in Guile. I remember talking to him about this issue several years ago, and I seem to recall that he didn't like the idea of merging the element types, but I don't remember his rationale. In any case, we should not proceed without his input. Andy, what do you think? Regards, Mark