From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: bytevector-copy creates srfi-4 vector with greater length Date: Mon, 27 Oct 2014 12:00:01 +0100 Message-ID: <87lho1bwwe.fsf@taylan.uni.cx> References: <544D09F6.8060309@posteo.eu> <87sii9j3ss.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414407626 4574 80.91.229.3 (27 Oct 2014 11:00:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2014 11:00:26 +0000 (UTC) Cc: tantalum , guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 27 12:00:16 2014 Return-path: Envelope-to: guile-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 1Xii23-0001Rz-Og for guile-devel@m.gmane.org; Mon, 27 Oct 2014 12:00:15 +0100 Original-Received: from localhost ([::1]:60671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xii23-0005H4-E7 for guile-devel@m.gmane.org; Mon, 27 Oct 2014 07:00:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xii20-0005Ep-9e for guile-devel@gnu.org; Mon, 27 Oct 2014 07:00:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xii1w-0003iM-0Z for guile-devel@gnu.org; Mon, 27 Oct 2014 07:00:12 -0400 Original-Received: from mail-la0-x22e.google.com ([2a00:1450:4010:c03::22e]:54365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xii1v-0003ZJ-Q9 for guile-devel@gnu.org; Mon, 27 Oct 2014 07:00:07 -0400 Original-Received: by mail-la0-f46.google.com with SMTP id gi9so5517546lab.5 for ; Mon, 27 Oct 2014 04:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=y90t4dEeI0J1u2rVPFzcivRJeX6mPPAgi6nQvNXddvs=; b=JeWBcQjXmF/opQxP1Iu/jYDydlGYaCTHBE00xakjr8rOm4MxkzDYarNOX8QIr5rm4V PBlmAQ4W83I17TY9v6eSScf+7pBRb2am7O0NEmo+vb14niiRjEH903kGWbzheZnQvbkT RD52OCrLT7hNSzKMeLr9MX3BjMEue3UfYW45me6h2wJQ1NRNGRCjRoLPYJIdMyjoyF5o 5e0qhSWvdNMnanLsZVGjriBU6mtxTjmzKOCoj1wd4/eyhKh7dYNCNlrSVDIOxzNS7zeR XTNf88YAmgSgUbfXRW6Tt3Sq/uNON9g85+VooMWMEb+jpXReDM4uQ/Kr4FmV7f5JE4Js XoWw== X-Received: by 10.152.116.102 with SMTP id jv6mr22853978lab.40.1414407603825; Mon, 27 Oct 2014 04:00:03 -0700 (PDT) Original-Received: from taylan.uni.cx (p200300514A13A2B40213E8FFFEED36FB.dip0.t-ipconnect.de. [2003:51:4a13:a2b4:213:e8ff:feed:36fb]) by mx.google.com with ESMTPSA id lm4sm387230lac.35.2014.10.27.04.00.02 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 27 Oct 2014 04:00:03 -0700 (PDT) In-Reply-To: <87sii9j3ss.fsf@netris.org> (Mark H. Weaver's message of "Mon, 27 Oct 2014 04:49:07 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17596 Archived-At: Mark H Weaver writes: > Thoughts? I have no experience with SRFI-4 so don't know what would be most pragmatic, but reading the specification, I see s8vector, u8vector, s16vector, etc. are all distinct data types, though u8vector corresponds to u8vector from SRFI-66, bytevectors from R6RS, and bytevectors from R7RS. Thus I would expect those four to be the same data type, and distinct from the other SRFI-4 types. Correspondingly, I'd expect the SRFI-4/66 u8vector and R6/7RS bytevector APIs all to work on that type and only that type. Other types from SRFI-4 should have their dedicated APIs, including a copy procedure. That seems like the relatively obvious Right Way to me, unless I'm missing something. If useful, there could be a separate API of procedures that work on both u8vector (i.e. bytevector) and other SRFI-4 data types, but otherwise I'm of the opinion that any distinct data type exposed to Scheme users should also have its dedicated API that works on no other types. Taylan