guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

wip-array-refactor strikes back


From: Andy Wingo
Subject: wip-array-refactor strikes back
Date: Thu, 07 Jan 2010 16:15:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hello,

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.

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!

Note that in the commit 8d96eb2afbfe7c321e69ca482c85755ddc9de6e0, the
note that "This does introduce the bug that #vu8(1 2 3) will compile to
#u8(1 2 3). I'm working on that" is incorrect, and will be removed.

So, Ludo! You seem to be the one to convince. Can I commit that, and
then bytecode-subrs? :)

Andy
-- 
http://wingolog.org/




reply via email to

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