[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb643
From: |
Ludovic Courtès |
Subject: |
Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509 |
Date: |
Fri, 19 Jun 2009 10:20:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) |
Hi,
Andy Wingo <address@hidden> writes:
> On Thu 18 Jun 2009 22:28, address@hidden (Ludovic Courtès) writes:
>
>> Andy Wingo <address@hidden> writes:
>>
>>>>> + uniform-array->bytevector
>>>>
>>>> I would not export it from `(rnrs bytevector)' given that it has nothing
>>>> to do with RnRS.
>>>
>>> No, but it does have to with bytevectors... Where would you put it?
>>
>> Dunno, maybe not anywhere public?
>
> Er, I wrote it so I could use it in my code... Not being able to get at
> the bits of uniform arrays from Scheme has been a sorely missing feature
> for a long time now...
I understand it's needed by the compiler to serialize uniform arrays,
which is a good reason to keep it public.
My concern is that IMO we should avoid encouraging applications to mix
uniform vectors and bytevectors, when the latter should be the main way
to do binary I/O.
>>>> Also, I would make the new C functions private, given that they are not
>>>> intended for general use AIUI.
>>>
>>> Dunno. I could imagine calling both of them from C. Would there be a
>>> problem with leaving them to be public?
>>
>> Yes, while we're not more confident wrt. shared arrays and similar.
>
> What do you mean? I think that shared arrays will be attempted to be
> linearized via scm_array_contents, which will throw an error for a
> non-contiguous array. That's as good as we can do, no?
That's right (it wasn't all that clear to me from our discussion).
Thanks,
Ludo'.