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).