From: "Arthur A. Gleckler" <arthur_at_zurich.csail.mit.edu>
Subject: Re: [r6rs-discuss] Scheme should not be changed to be case sensitive
Date: Thu, 16 Nov 2006 20:29:51 -0800
> On Nov 16, 2006, at 2:58 PM, Shiro Kawai wrote:
>
> > 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.
>
> Simplicity and ease of communication and explication are two of the
> reasons I want Scheme to remain case insensitive. Not having to say
> "Boolean -- no, that's capital Boolean -- no, just the 'b' is
> capitalized" would be great. Not having to deal with errors
> introduced by the kind of crazy capitalization I suffer with in Java
> day in and day out would be wonderful. I don't want to lose those
> benefits in Scheme, especially after having them all these years.
I feel that we really live in different worlds.
What I meant is the simplicity of the language spec. But anyway.
The example you mentioned is very culture-specific.
In my experience, it often requires far more effort to tell
the right spelling than to tell the right capitalization---with
some coding standard, non-english-native programmers can
do the latter mostly right, while not the former.
Besides you don't need to do CamelCase even if R6RS becomes
case sensitive. Probably you (and most Scheme programmers)
would never use a symbol "Boolean". Unless you want to stick the
convention such as capitalizing the definitions to emphasize them,
you don't need to change your coding style at all. (And those
"emphasis by capitalizing" is also culture-specific, only
applicable to the languages that have lower/upper case distinction.)
The bonus is, when you import Xlib, for example, you can use
variables XK_A and XK_a without awkward quoting like |XK_A| and
|XK_a| --- those special treatments are far more bothersome,
since it makes those variables stand out in the source, while
they are nothing more special than other normal variables.
> > 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.
>
> The library forms are up for debate, too. The enclosure of LIBRARY
> forms is one of the things I least like about the current library
> proposal -- that effectively, most files will be just one giant
> LIBRARY form. This is one more thing that's not just neutral to
> interactivity, but detrimental to it.
Well, I myself do not like that, too. One thing is that
it requires the implementation to read the whole library
at once to start compiling/interpreting it; which can be
a burden for small, lightweight implementation.
But that's not the point. As far as the implementation
provides the means to load R5RS sources, I don't mind
R6RS breaks backward compatibility, as far as it allows
us to explore wider design space. So I like your argument
about communication above, which isn't based on the
backward compatibility. I keep my position, but I'd
like to hear other people's opinions.
--shiro
Received on Fri Nov 17 2006 - 02:14:34 UTC