[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)


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.


> 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?


reply via email to

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