home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / scheme / 2551 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  2.6 KB
  1. Path: sparky!uunet!stanford.edu!agate!anarres.CS.Berkeley.EDU!bh
  2. From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re: case sensitivity
  5. Date: 6 Nov 1992 16:00:49 GMT
  6. Organization: University of California, Berkeley
  7. Lines: 45
  8. Distribution: world
  9. Message-ID: <1de4rhINNn4u@agate.berkeley.edu>
  10. References: <1992Nov6.062357.8865@Informatik.TU-Muenchen.DE>
  11. NNTP-Posting-Host: anarres.cs.berkeley.edu
  12.  
  13. kobler@informatik.tu-muenchen.de (Daniel Kobler) writes:
  14. >    'Wall is claimed to be the same as 'WALL,
  15. >
  16. >whereas
  17. >
  18. >    (string->symbol "Wall") and (string->symbol "WALL") are different.
  19. >
  20. >And again my question: why these differences? Wouldn't it be better to
  21. >do it the one OR the other way, i.e. allow symbols with upper/lower
  22. >case letters or strictly converting all letters inside symbol names to
  23. >the case preferred by the respective implementation?
  24.  
  25. It *would* be nice, I think, if someone more qualified than I wrote a
  26. summary article called "The Philosophy of Scheme" or something like that
  27. explaining how things like this come about.
  28.  
  29. But, ever foolhardy, I'll throw in my partial understanding...
  30.  
  31. One traditional Lisp idea that has been pretty thoroughly rejected in
  32. Scheme is that of programs constructing programs and then evaluating
  33. them.  If you're accustomed to manipulating program text as data (as
  34. opposed to manipulating executable bits of program -- functions -- as
  35. data, which Scheme *does* support) then along with that you're accustomed
  36. to thinking of a symbol as a kind of text string.  Traditional Lisp
  37. systems support this way of thinking by providing things like EXPLODE
  38. and IMPLODE that encourage messing around with the characters in a symbol.
  39.  
  40. On the Scheme view, a symbol is a seamless black box.  It's just as a
  41. concession to human memory that symbols have letters in them at all;
  42. from Scheme's point of view it would be just as good if you had a keyboard
  43. with a few hundred unlabelled keys, each of which was a single-keystroke
  44. symbol.
  45.  
  46. string->symbol is a concession to people with unusual needs.  The reason
  47. it doesn't follow the usual rules for symbols is that it exists precisely
  48. as a mechanism to escape from those rules.  Using string->symbol is
  49. cheating, sort of like using goto in some other languages.
  50.  
  51.  
  52. (P.S.  If this doesn't come out quite right it's because I'm trying to
  53. express a view that isn't mine.  Personally I find that I spend far too
  54. much time putzing with details about characters vs. strings vs. symbols;
  55. for my simple mind the Logo approach in which there is just one data type
  56. called Word that fills all these roles is easier.  But of course it's
  57. less efficient the Logo way.)
  58.