Subject: bug#18224: closed (Re: bug-guile Digest, Vol 137, Issue 2)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 30 Oct 2015 16:16:03 +0000

Your bug report

#18224: Shared arrays are incompatible with bytevector accessors

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
18224: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18224
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug-guile Digest, Vol 137, Issue 2
From: Daniel Llorens <[email-masked]>
To: [email-masked]
Date: Fri, 30 Oct 2015 17:15:21 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=eb3d623da57e6d31a58d95f932345fb761f9b701 on master fixes printing of scm_tc7_array (shared array) to be #1(...) or #1typetag(...) so they aren't confused with actual vectors or bytevectors.

With respect to the lack of capability to create shared bytevectors, use the array procedures instead. If you need the arrays to be contiguous, you can check this at run time.

The fundamental distinction between shared arrays on one side and bytevectors/vectors/bitvectors on the other side is not of contiguity, rank, element type, etc. but that the latter types are containers, while the shared arrays are just views. That is why I don't think indirection fields should be added to the bytevectors, this would complicate the lookup functions and overlap in functionality with arrays.

Subject: Shared arrays are incompatible with bytevector accessors
From: Panicz Maciej Godek <[email-masked]>
To: [email-masked]
Date: Fri, 8 Aug 2014 16:48:08 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Creating a shared array based on a bytevector results with an object
whose print representation is identical with a print-representation of
a bytevector:

(define bv #vu8(0 1 2 3))

(define bv/shared
  (make-shared-array bv (lambda(i)(list (+ i 2))) '(0 1)))
bv/shared
====> #vu8(2 3)

However, accessing these "shared bytevectors" using the bytevector api
is impossible:

(bytevector-u8-ref bv/shared 0)
====> error: wrong type argument in position 1 (expecting bytevector): #vu8(2 3)

Since the print-representation is identical, this behaviour is
unexpected. Furthermore, the lack of capability of creating shared
bytevectors limits their usefullness. On the other hand, if the shared
bytevector remains contiguous, there should be no performance
concerns.