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.
On Jul 20, 2008, at 5:33 AM, higepon wrote:
(a) Raises an exception (natural, but may be inconvenient in some cases)(b) Returns some value indicating such condition has happened (c) Allow an optional 'filter' argument.I think (a) is good. It is enough for my usage (CGI applications). What cases are inconvenient? Procedures return raw value(s) are necessary?
One other inconvenience is that you have to wrap every call to get-environment-variable with some sort of a guard. I like option c the best, as it provides a good default behavior, does not clutter the interface with duplicate procedures, and, more importantly, it usage is simple and clear. E.g., (get-environment-variable "HTTP_REQUEST" url-decode) 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?) 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).