[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getenv vs. locale

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