From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: tantalum Newsgroups: gmane.lisp.guile.devel Subject: Re: bytevector-copy creates srfi-4 vector with greater length Date: Mon, 27 Oct 2014 13:36:06 +0100 Message-ID: References: <544D09F6.8060309@posteo.eu> <87sii9j3ss.fsf@netris.org> <87lho1bwwe.fsf@taylan.uni.cx> Reply-To: sph@posteo.eu NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1414413394 5049 80.91.229.3 (27 Oct 2014 12:36:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2014 12:36:34 +0000 (UTC) Cc: Mark H Weaver , guile-devel@gnu.org To: taylanbayirli@gmail.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 27 13:36:27 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 1XijX8-0000ME-12 for guile-devel@m.gmane.org; Mon, 27 Oct 2014 13:36:26 +0100 Original-Received: from localhost ([::1]:33426 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XijX7-0001mn-1p for guile-devel@m.gmane.org; Mon, 27 Oct 2014 08:36:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XijWz-0001ma-Je for guile-devel@gnu.org; Mon, 27 Oct 2014 08:36:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XijWu-0002WD-CG for guile-devel@gnu.org; Mon, 27 Oct 2014 08:36:17 -0400 Original-Received: from mx02.posteo.de ([89.146.194.165]:52517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XijWu-0002Vs-7O for guile-devel@gnu.org; Mon, 27 Oct 2014 08:36:12 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mx02.posteo.de (Postfix) with ESMTP id 21CE725AF519; Mon, 27 Oct 2014 13:36:10 +0100 (CET) X-Virus-Scanned: amavisd-new at posteo.de Original-Received: from posteo.de ([10.125.125.178]) (using TLS) by localhost (amavis1.posteo.de [10.125.125.165]) (amavisd-new, port 10026) with ESMTPS id ZXolpfX8kAuk; Mon, 27 Oct 2014 13:36:08 +0100 (CET) Original-Received: from mail.posteo.de (localhost [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTPSA id A389E2C0100; Mon, 27 Oct 2014 13:36:06 +0100 (CET) Mail-Reply-To: sph@posteo.eu In-Reply-To: <87lho1bwwe.fsf@taylan.uni.cx> X-Sender: sph@posteo.eu User-Agent: Posteo Webmail X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 89.146.194.165 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:17597 Archived-At: from the explanations in the manual i interpret the definition of the srfi-4 compatibility to be "can work on srfi-4 vectors because the storage is the same, even though it regards the data as 8-bit values" i looked at the code and it seems to work just like this for the read and write part of the copy. for the creation part it uses make-bytevector with the input type copied in a generic way - i think this is sound so far because it does not include any special cases for working with srfi-4 types. the main problem may be that SCM_BYTEVECTOR_LENGTH returns the wrong length - that it does not follow 8-bit interpretation if bytevector-copy would have a input/output type discrepancy, then the general bytevector/srfi-4 compatibility as i understand it would be in question - read supported, but not create or write. bytevector-copy! has the same issues On 27.10.2014 12:00, taylanbayirli@gmail.com wrote: > 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