¡Hola! Andy Wingo <wi...@pobox.com> 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’.
