Peter Bex wrote:
> That's just silly.  The user can get a proper font, this is not
> something the language needs to work around.  Next you'll say we need to
> force uppercase identifiers because the number 1 and the letter l can be
> confused too easily otherwise!
> Also, what the hell kind of font confuses these two letters?  t looks
> like an upside-down f in most fonts, which is a very clear difference.

I agree. The pipe symbol, |, could also be confused with 1 and l;
the number 7 with 1...
The same is true for the letter oh and the number zero; curly braces with
parens, and so on. But the programmer can avoid those problems by choosing
a font that was *designed* for programming. In a couple of minutes searching
it's possible to find sites comparing and recommending different fonts for
programmers. Some of them [1] will even show you these strings in different
fonts:

0Oo
I1l|
,.
;:

Syntax-highlighting may also help, depending on how comfortable the
programmer is with using colors.

> If you're afraid they get confused, allow them to be case-insensitive:
> #T is very different from #F, and that's already supported by most
> Schemes.

And it's also trivial do (define true #t), (define false #f).
Much easier and with less side-effects than changing the language.

There's one more problem with switching to #false and #true. Tutorials,
books and other instructional material becomes confusing to students --
even if the old names are kept in a library. A text written with examples
in R5RS, for instance, will not work immediately (without the need to
load libraries) with R7RS (neither will things work the other way around).
There should be a stronger reason to change standard lexical tokens in the
language. Otherwise, one could also argue that car and cdr
could also be changed to first and rest -- not only because their
meaning is not immediately and intuitively apparent, but also because
they only differ in their second character, and hence it's possible to
confuse both -- or propose other similar changes [2]. But that would totally
break compatibility with older versions of the standard, and also with any
texts written previously using those previous standards.

J.

[1] For instance, http://vim.wikia.com/wiki/The_perfect_programming_font

[2] Another argument, not as acceptable but still consistent, is that
   "define-variable" is more explicit and clearer than "define", and the
   language would also feel more uniform, since there is "define-syntax"
   already. To be even more uniform, one could have "define-variable",
   "define-syntax" and "define-function" (for abbreviated function
   definitions, with implicit lambda).

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports