Neil Jerram <[EMAIL PROTECTED]> writes: >> Also, you definitely can't judge by the presence or lack of >> documentation. Guile's documentation has often taken a while to >> catch up with the code. > > I'm not sure I agree with that. I accept that documentation can > sometimes take a while to catch up (although it shouldn't, and > recently I think we've all been pretty good about writing doc at the > same time as developing something), but in principle I think > "presence in the manual" is a better way of indicating to users > whether an API is officially supported than a coding convention.
Well, if that's how we want to proceed, then I think we need to be very clear about it. My understanding has been that we promse that as a default, any C feature that's prefixed with scm_ instead of scm_i_ is fair game for the C programmer and that they can expect us to maintain it going forward (plus or minus deprecation, *major* (i.e. 2.0) releases, etc.). In the past (at least), this was important because there were a lot of things not mentioned in the documentation. Further, as with the SRFI code, the automatic documentation mechanism hasn't included the C documentation, even when it exists, and even if our documentation becomes (has become) more or less comprehensive, I still feel like the scm_ vs scm_i_ convention is a good one. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
