This page is part of the web mail archives of SRFI 97 from before July 7th, 2015. The new archives for SRFI 97 contain all messages, not just those from before July 7th, 2015.
Date: Wed, 26 Mar 2008 11:20:39 -0400 (EDT) From: AndrevanTonder <andre@xxxxxxxxxxxxx> I would suggest that the export level be assumed to be 0 for all exported bindings of all SRFIs /except/ SRFI-46: Basic syntax-rules extensions, which should export SYNTAX-RULES for level 1, provided the author agrees. I agree that this is the right thing to do for the R6RS. SRFI 9, Defining Record Types, and R6RS Records. What relation should SRFI 9 records have with R6RS records? I do not think any relationship should be assumed. It might not be in harmony with the intent of the author, but even if it is, assuming a relationship would amount to an effective post-finalization modification or extension of SRFI-9 itself, which would defeat the purpose of the actual original SRFI process. Would any assumed or stated relationship affect the semantics of programs written with SRFI 9? Certain programs might lose certain abstraction barriers, but that is not so harmful as a loss of guarantees of security, of which SRFI 9 made none. Identifying SRFI 9 records with the R6RS's records, on the other hand, would avoid certain social problems that persistently plague Scheme, probably at very little technical cost. This is a tricky one. One has no choice but to export some bindings for the conflicting literals (if, not, and, or). If one re-exports the same bindings as (rnrs base) for these conflicting literals, the library will be more convenient to import into most programs. However, one then cannot write a program that uses SRFI-42 but that, at the same time, excludes the (rnrs base) meaning of IF (as for example PLT 4 that excludes one-armed IF). It would really be much cleaner to export different bindings for these literals, but then they would have to be renamed if imported into an (rnrs base) program, which is inconvenient. One could argue that importing a library that exports a non-standard meaning of the name IF so fundamentally changes the meaning of the name so that it should no longer retain its meaning within miniature languages such as SRFI 42. I don't expect to be persuaded strongly by any such argument, however. It is not clear that hygienic name comparison is the right thing to do for many cases. Whether it is the right thing for COND is debatable -- I know that one might like to write code along the lines of (LET ((THEN (MUMBLE FOO)) (ELSE (GRUMBLE FOO))) (COND ((AND THEN ELSE) (EMIT-BRANCH THEN ELSE)) (THEN (EMIT-THEN THEN)) (ELSE (EMIT-ELSE ELSE))) (EMIT-JOIN FOO)), but this is hardly persuasive (even though I have stumbled across this kind of code in the wild). I can abstractly imagine a context in which it is infeasible to avoid the use of a certain name: in a pathological combination of two restricted miniature languages, in one of which there is a language keyword -- say FOO --, and in the other of which there is a variable-like thing also called FOO, and a use case where it is impossible to refer to variable-like things in any semantically equivalent but syntactically distinct way. For instance, suppose we strip BEGIN, LAMBDA, and everything else similar from the language so that we can't refer to a variable in any different way like (BEGIN FOO), and introduce a LET-ELSE form to bind a single variable named ELSE, and strip any other binding forms so that we can't refer to ELSE by any other name. Then we shall have a problem using COND when our variable ELSE is a potential condition: either we can't use COND's ELSE clauses, or we can't refer to our variable ELSE in the condition position. Is this mind-numbingly pathological? Yep. I'm curious to hear whether anyone else has any practical examples of a pair of languages resistant to combination in this way. There are other contexts where it hygienic name comparison buys one nothing, such as CASE's ELSE clauses. There is absolutely no way to use a name ELSE meaning anything else in the same context in a CASE. So it really would be nice to introduce non-hygienic name comparison for cases where it is useful. And both CASE and SRFI 42 are examples of such cases where non-hygienic name comparison is useful. Perhaps the author can be persuaded to use his colon-based naming convention for keywords uniformly (making it :and, :or, ... for uniformity with :range, ...). The author of SRFI 42 may be persuaded of that, but not this author of other miniature languages with similar syntactic characteristics. (Very little of my code will run in the R6RS anyway, because of gratuitously incompatible changes to the language, of course, so perhaps my opinion doesn't matter here.)