This page is part of the web mail archives of SRFI 98 from before July 7th, 2015. The new archives for SRFI 98 contain all messages, not just those from before July 7th, 2015.
Please consider having two separate SRFIs: one SRFI uses strings, corresponds to current practice, and is likely to become widely implemented and accepted the other SRFI uses bytevectors, does not correspond to current practice, is likely to be implemented only by some fraction of the minority of systems that implement either SRFI 4 or the R6RS, and is likely to be used only by programmers who use those systems This is a case where solving 99.999% of the problem with a solution that uses a data structure supported by 100% of the leading implementations is likely to be better than trying to solve 100% of the problem by using two different data structures, each of which is supported by at most 25% of the leading implementations. Abdulaziz Ghuloum asked: > As for R6RS bytevectors vs. SRFI-4 u8-vectors issue, well, you > can define this filter procedure to take either a bytevector or > a u8-vector and it won't matter much in practice: no system is > going to support both R6RS bytevectors and SRFI-4 u8-vectors at > the same time (right?)... Wrong. Users of both PLT Scheme and Larceny are already writing significant programs that combine R5RS SRFIs with ERR5RS/R6RS libraries, and that kind of interoperability will only become more important as ERR5RS/R6RS libraries grow in popularity. > ...and if you write a program using this > SRFI, you're going to either write it for an R6RS implementation > (in which case you'd be using a bytevector and your library will > be okay in all R6RS implementations that support this SRFI), or > you will write your code for an R5RS implementation (in which > case you'll use whatever byte array representation that your > implementation provides). Users of PLT Scheme are already having to marshall their lists when passing them from PLT-native code to R5RS or R6RS code, or in the opposite direction. Please don't inflict that kind of marshalling on everyone who uses getenv in an R5RS/R6RS-capable system. Shiro Kawait wrote: > Ultimately, the choice depends on the purpose of this srfi. > If this one just wants to summarize "current practices", leave > the behavior undefined and cross your fingers that it works > "most of the time". If this one wants to provide a portable > and robust basis, specify the behavior and encourage existing > implementations to follow. I tend to vote the latter. If you want portable and robust behavior, then you should try to avoid data structures (such as bytevectors) that are not even implemented by a lot of systems, and have competing lexical syntax and semantics (SRFI 4 vs R6RS) even when implemented. Will