Re: review/merge request: wip-array-refactor

[Andy Wingo <wingo@pobox.com>]

Hi Neil,

Thanks for the review.

On Wed 22 Jul 2009 23:48, Neil Jerram <neil@ossau.uklinux.net> writes:

> I have two overall questions in mind.
>
> - What do you have in mind as regards releasing this?  Even though it
>   looks good, I think it would be better to let it mature for a while,
>   and hence not to put it into 1.9.x/2.0.  (And we're not short of new
>   stuff in 1.9.x/2.0!)

Personally I would prefer that it come out in 2.0. I'm fairly (but not
entirely) confident of its consistency as it is, and quite confident
that it is a more maintainable, and hence fixable, codebase.

The reason that I want it in is that bytevectors are a nice api for I/O,
but once you have data in memory, often it's best to treat it as a
uniform array -- be it of u8 color components, or s32 audio samples.

Uniform vectors are almost by nature "in flight" between two places. But
it is the bytevector that is most equipped to "fly", via e.g. (rnrs io
ports); but bytevectors do not provide an ideal API for manipulation.
s32vector-ref is a better API than bytevector-s32-native-ref, if only
that the offset of the former is in native units (s32 elements), and of
the second in bytes.

I guess what I wanted to do was break uniform vectors out of their type
ghettoes. Like Perlis said, "Pascal is for building pyramids --
imposing, breathtaking, static structures built by armies pushing heavy
blocks into place. Lisp is for building organisms -- imposing,
breathtaking, dynamic structures built by squads fitting fluctuating
myriads of simpler organisms into place." I should be able to put a
64-bit float into two 32-bit words, when I'm writing an instruction
sequence for a 32-bit machine, without having to change my data type --
they are just bytes anyway.

> - What about the header file incompatibilities?  I.e. the problem that
>   if there are applications out that that #include <libguile/ramap.h>,
>   or another of the renamed ones, they will stop working.  Do you
>   think we are OK just to document this well, or should we do more
>   than that?

I thought that our only support API was that provided by #include
<libguile.h>.

We can add back compatibility header files if necessary. Do you think it
is necessary?

>> The only bits I could anticipate being controversial would be the last
>> two or three patches, in which bytevectors are given an "element type"
>> field. This is so that I can make the srfi-4 uniform vector code use
>> bytevectors as their representation -- it's one less orthogonal type
>> that the VM would have to deal with.
>>
>> Those patches also allow uniform vectors of one type to be accessed
>> using accessors for other types:
>>
> What is the detailed rationale for [the following examples]?

>>   (u8vector-ref #u32(#xffffffff) 0) => 255

I ought to be able to get at the bits of a packed (uniform) vector. The
whole point of being a uniform vector is to specify a certain bit layout
of your data.

>>   (u8vector? #u32(#xffffffff)) => #f

However, we need to preserve type dispatch:

  (cond
    ((u8vector? x) ...)
    ((s8vector? x) ...)
    ...)

>>   (bytevector? #u32(#xffffffff)) => #t

This to me is like allowing (integer? 1) and (integer? 1.0); in
/essence/ a #u32 is an array of bytes, interpreted in a certain way. In
practice, one might use real? / complex? / integer? / etc to distinguish
elements of the numeric tower; in this case we have a short tower:
uniform vectors are bytevectors.

>> commit 86d88a223c64276e7cd9b4503e7e2ecca5aae320
>> Author: Andy Wingo <wingo@pobox.com>
>> Date:   Thu Jul 16 21:51:47 2009 +0200
>>
>>     remove deprecated functions from unif.c
>>     
>>     * libguile/unif.h:
>>     * libguile/unif.c: Remove deprecated functions.
>>     
>>     * module/ice-9/deprecated.scm: Remove array-related deprecated
>>       functions.
>>     
>>     * NEWS: Update.
>
> I can understand why a lot of the NEWS deltas evaporate when they are
> logically merged into the 1.8-2.0 section, but I'm not sure about
>
> - the entry for Brainfuck
>
> - the entry on scm_set_port_seek and scm_set_port_truncate
>
> Aren't these entries still of interest?
>
> The rest of this commit looks fine.

Yes they are. Good catch.

I'll finish this response, and the response to Ludovic, later -- but I
wanted to get out the rationale now. Thanks again for the review!

Andy

-- 
http://wingolog.org/