guile-devel
[Top][All Lists]
Advanced

[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'.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]