[r6rs-discuss] [Formal] SRFI-39 should be made an R6RS library

From: R. Kent Dybvig <dyb>
Date: Sun Feb 11 12:35:21 2007

> Why not just use ordinary Scheme top-level variables, then, and use
> SET! to change them on the occasions when it might be required?
> Why use separate machinery for them?

One motivation is that such top-level variables essentially become
reserved words. One cannot redefine them at top level without affecting
the code that references them. For example, if the reader and printer
consult the variable case-sensitive and some application defines it for
its own purposes, the behavior of the reader and printer changes as the
value of the application's variable changes.

On the other hand, if the reader and printer consult the parameter
case-sensitive and some application redefines it for its own purposes, the
reader and printer are unaffected. In general, an application can
redefine the name of any parameter for its own purposes, and it can give a
parameter a different name if it needs to use the parameter.

This motivation is not as strong if applications use libraries and avoid
the top level.

Another motivation is that parameter values can be checked at the point of
assignment rather than at the point of reference. For example, the
parameter print-level in Chez Scheme must be #f or a nonnegative integer,
and a violation of this restriction is signaled when the parameter is set
(called with the new print-level). As a result, the user gets feedback
when the error occurs, and the printer need not check the value whenever
it accesses the parameter.

> OT: I've noticed a tendency in Scheme libraries to eschew global value
> definitions for functions that return a constant value. Has anyone
> else noticed this (I can't point to evidence offhand), and does anyone
> know why?

I can't speak to this in general, but when I do so it's for reasons
similar to the first given above and also to prevent users from changing
the supposed constant.

Kent
Received on Sun Feb 11 2007 - 12:34:44 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC