[r6rs-discuss] r6rs-discuss Digest, Vol 9, Issue 1

From: Paul Schlie <schlie>
Date: Fri, 11 May 2007 17:23:05 -0400

> John Cowan scripsit:
>> Paul Schlie scripsit:
>> I don't believe [...] that scheme programs should be allowed to be
>> formulated from anything other than the ASCII character alphabet
>> as this restriction helps keep the core language implementation
>> simple and encourages the development of more uniformly legible
>> source code, as opposed to programs utilizing arbitrary alphabets).
>
> Uniformly legible to whom? If Scheme programs are limited to ASCII,
> they are also implicitly limited to those who read and write American
> English. I am told that one of the early attractions of Java in Japan
> was the ability to write programs with identifiers that were meaningful
> in Japanese, thus liberating Japanese programmers from the burden of
> deciphering either English or their own language in transliteration.

- I understand the sentiment; however the facts are that differing
  languages/dialects divide communities, they don't unite them; as
  the lack of a common means of expression inhibit the sharing of
  information, conducting commerce, etc.; thereby for good or bad, as
  world's most broadly adopted language (even if only secondary) is
  English for just these reasons; it seems fairly clear that adopting a
  facility which in effect enables a community to diverge from such
  a common language/dialect is actually most likely counter productive;
  in my opinion, attempting to learn from history.

  However I see no reason why such a standard would prohibit an
  implementation's reader/parser from being extended to enable it to
  dynamically transliterate identifiers expressed in an arbitrary alphabet
  to correspondingly unique ASCII identifier strings, which may be then
  read/parsed generically; in fact it would seem that if a unicode/text
  manipulation library were defined, and the logical port from which
  REPL sources/sinks i/o, such an extension could be invoked and
  encapsulated within an optional library, without having to increase
  the size or complexity of the core language/environment.

(I realize the subject is contentious and likely not worth further debate,
 especially as this is just my opinion and I have nothing more to add)
Received on Fri May 11 2007 - 17:23:05 UTC