[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wip-array-refactor strikes back
From: |
Ludovic Courtès |
Subject: |
Re: wip-array-refactor strikes back |
Date: |
Thu, 07 Jan 2010 21:33:44 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
¡Hola!
Andy Wingo <address@hidden> writes:
> I was hacking on the bytecode-subrs the other day when I realized that I
> wanted the "backing store" of programmatically constructed objcode to
> not be a smob type. At that point it was a u8vector.
OK.
> So, I thought, what better way to do that than to resurrect the
> wip-array-refactor branch, which represents all srfi-4 vectors as
> bytevectors. So here I am pushing that branch again.
>
> Reasons why we should merge wip-array-refactor:
>
> * Massive reduction in C code. 'Nuff said.
>
> * Passes all the test suites, and maintains existing C API.
>
> * We wanted the bytecode format to be bytevectors anyway. This effects
> that change at the data representation level, allowing us to lazily
> convert over the Scheme code that writes it (since building a #u8()
> is the same as building a #vu8()).
>
> * Allows bytevectors to be referenced using u32vector-ref and friends.
> I know this is a slightly controversial point, but I see no reason
> not to allow this. Actually prohibiting u32vector-ref from working
> on bytevectors would actually be more code!
Well, that’s how it currently works, so I guess it’s less code, isn’t
it? :-)
> So, Ludo! You seem to be the one to convince. Can I commit that, and
> then bytecode-subrs? :)
Well, presented this way, I have no other choice but to say yes! ;-)
If that’s not already done, can you make sure to add bits of
documentation for the new semantics along the way?
Thanks,
Ludo’.