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

[ludo@gnu.org (Ludovic Courtès)]

Hi Andy!

Andy Wingo <wingo@pobox.com> writes:

> The second model is when you already have a wide deployed base. You can
> make additions to your API and ABI, and deprecated old API or ABI, but
> you can't remove old API or change the ABI. Incompatible breaks are
> painful, and the switching-over time is somewhere between a year and
> three years. The right length of a stable series seems to be about 4 or
> 5 years.

I'm in favor of sticking to this model, i.e., paying attention to both
source and binary compatibility.  That sounds important to me as Guile
is an old piece of software for which users may expect a relative
stability and clear upgrade path when that is needed.

>> (Not sure I agree.  I'd say uniform vectors are mostly holding numbers
>> in a computation, or for plotting on a graph.)
>
> But how do you plot? If you use some sort of external software, you have
> two options: code your plotting in C, and loop overx the data with the C
> API. Or do it in Scheme, and... loop over the s16vector, writing each
> sample individually? How do you get at the bits of the s16vector so they
> can be written to a port? Use the impoverished uniform-vector-write ?

My feeling is that if you plot using, say, GNUplot or Ploticus, you give
them ASCII-formatted numbers, so SRFI-4 is pointless; in other cases, I
suspect the application may use higher-level data types than u8vectors,
which means some conversion is needed anyway when exporting data
bit-wise.

> I've written lots of code that deals with srfi-4 vectors. I have three
> kinds of use cases. First is data being shoved around in a
> dynamically-typed system: dbus messages, gconf values, a system we 
> at work, etc. Second, but related, is dealing with chunks of data that
> come from elsewhere, like GDK pixbufs, or GStreamer buffers. Third is
> hacking compilers, as in Guile itself, or emitting machine code for
> other machines.

My feeling is that the 1st and 3rd use cases are what bytevectors were
written for in the first place.  They allow applications to avoid
reimplementing number serialization as in `write-bytecode' in
`assembly/compile/bytecode.scm'.

SRFI-4 is a good fit for the 2nd use case as you're dealing with
fixed-width native-endianness numbers coming from C code.  But in this
case, I don't think bytevectors are needed at all.

> In summary... I don't mean to be a bore, but I really don't like the
> existing unif.c and srfi-4.c. They are painful to understand and to hack
> on. I think those bits should be merged.

Agreed.

> I also think that srfi-4 vectors should be implemented in terms of
> bytevectors, for the reasons above.

I'm not convinced, but OTOH, I don't think it hurts.

Like Neil, the one thing that I'm not fond of is the switch from
disjoint SRFI-4 types to polymorphic types, because programming errors
that currently yield a `wrong-type-arg' error will be silently ignored.
The SRFI text allows it, but the rationale says that "the use of
homogeneous vectors allows certain errors to be caught earlier."

Thanks,
Ludo'.