Re: Miscellanea

[Taylor R Campbell <campbell@xxxxxxxxxx>]

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