[r6rs-discuss] Scheme should not be changed to be case sensitive

From: Shiro Kawai <shiro>
Date: Thu Nov 16 17:58:15 2006

From: Chris Hanson <cph_at_csail.mit.edu>
Subject: Re: [r6rs-discuss] Scheme should not be changed to be case sensitive
Date: Thu, 16 Nov 2006 13:44:58 -0500

> Shiro Kawai wrote:
> > Symbol case folding is not only a matter of the reader but
> > also affects the writer if we want to guarantee write-read
> > invariance. In Common Lisp, they are unified; both are
> > controlled by the value of readtable-case slot of the current
> > readtable. If we want R6RS to support both modes, we need a
> > dynamic scoped parameter that specifies the mode.
>
> Strictly speaking this isn't necessary. The output can be in any mode
> as long as it emits the correct prefix.

By prefix you mean some mark like #!fold-case? Well, it works,
but the story can be complicated.

For example, suppose I have a library that produces a string
representation of S-expression, which may be stored in a record
of RDBMS, or to be appended to a log file, or to be sent over
the newtork. Since the library doesn't know how the resulting
string will be used, should the library put the prefix in every
string it produces? We may have an option to specify whether
we need a prefix or not, but if the library is deep down in the
layers of other libraries, passing around such an option explicily
is tedious.

> > This still causes surprises when persistent data is
> > written in one mode and then read in another.
>
> Not if output is consistently tagged with a prefix.

In other words, what is the unit of 'output'? The port
may not know (since a part of output can be produced
by writing out a string port, who doesn't know the output
may be a part of larger output or not). The write routine
may not know (by the same reason). To be sure, we can
put teh tag wherever applicable, which may produce an output
cluttered by the tags.

It may be still a convenient means to tag the file to
indicate which mode the file wants to be read. I've been
using such kind of tag to indicate the character encoding
of the file, and it is working very well (I'm working
in the environment where the source files are written in
utf-8, euc-jp, shift-jis, and latin-1).

> > (And remember, no matter how large your current code base is,
> > we have to assume there will be more code to be written,
> > and mostly by people younger than us, who are used to
> > case-sensitive languages).
>
> I don't see how this is relevant -- what I'm suggesting supports case
> sensitivity in future code.

Suppose there will be a compatibility means so that you can use
existing code without a problem. Now you have an option to
redesign this feature of the language. According to the spirit
of Scheme ("Language should be designed ..."), which one is simpler
and cleaner, the one that has case-folding rule, and another that
has not? Think about teaching it to students, or training new
employees who have been programming in other popular languages.

> It also provides an upgrade path:
> implementations with large bodies of case-insensitive code can make that
> the default, and maintain backwards compatibility. Meanwhile, that
> legacy code can be incrementally modified by adding #!fold-case to the
> relevant files.

If I understand the current draft correctly, your R5RS libraries
can't be R6RS compatible as they are---you at least need to enclose
the entire body with (library ...) form. So R6RS itself does not
provide a gradual upgrade path anyway.

Of course, an implementation can provide a compatibility mode,
with which it allows to load R5RS libraries, and I believe many
will do (I'll make Gauche to do so). But if that's the case,
there's no problem for the implementation to have an option
to specify case-folding mode.

Other than the backward compatibility, which can be solved as
described above, what makes you think case-folding symbols has
benefits?

--shiro
Received on Thu Nov 16 2006 - 17:58:21 UTC