Hello Ludovic :) On Sun 09 Aug 2009 18:41, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo <wi...@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. I agree. >> 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. Agreed. > 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. Agreed, modulo the possibility for this data to be embedded within some other stream. > But in this case, I don't think bytevectors are needed at all. I think they are needed whenever you want to *do* something with this data -- i/o for example. >> 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. OK, I'll see about merging up until the polymorphic change after the release. >> 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." OK. Hopefully when I do my merge, the advantages/disadvantages of the various approaches will be more clear to all of us (including myself). Cheers, Andy -- http://wingolog.org/
