home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / scheme / 2815 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.4 KB

  1. Path: sparky!uunet!paladin.american.edu!gatech!usenet.ins.cwru.edu!agate!anarres.CS.Berkeley.EDU!bh
  2. From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re: Spread of Scheme and SICP?
  5. Date: 22 Dec 1992 20:16:46 GMT
  6. Organization: University of California, Berkeley
  7. Lines: 50
  8. Message-ID: <1h7t3eINNgd@agate.berkeley.edu>
  9. References: <921222144636_71020.1774_EHC61-1@CompuServe.COM>
  10. NNTP-Posting-Host: anarres.cs.berkeley.edu
  11.  
  12. 71020.1774@compuserve.COM (Terry Kaufman) writes:
  13. >It would be a mistake to discourage high school teachers from using
  14. >Scheme.  Besides as it continues to grow in popularity at the university
  15. >level, Scheme has a much better chance than Logo to displace BASIC and
  16. >Pascal in high schools.
  17.  
  18. I have mixed feelings about this.  As far as the core of the two languages is
  19. concerned, I agree that Scheme has both easier-to-understand [although maybe
  20. *initially* more intimidating] syntax and greater expressive power [i.e.,
  21. lambda].  But two things work in Logo's favor, and I think at least one of
  22. them should be addressed in R(N+1)RS:
  23.  
  24. 1.  Debugging is easier in Logo, for a beginner, for two reasons:  (a) the
  25. default behavior on an error is *not* to put you in some screwy debugging
  26. sub-language that you don't understand; and (b) dynamic scope makes it very
  27. easy to ask for all the relevant variables, without having to know about
  28. frames, stacks, etc.
  29.  
  30. This is the one I think could be addressed in the standard.  I'd like it to
  31. be standard behavior that you have to ask for a debugger before you get one.
  32. Going along with that, the error message you see should be more complete,
  33. telling you the expression that failed and the name (if any) of the procedure
  34. in which it occurred.  [I know that that's hard to get right in a tail
  35. recursive interpreter, but I can do it in Berkeley Logo, so it can be done!]
  36. That would take care of part (a).
  37.  
  38. For part (b), I'd like to see a standard notation for asking for something
  39. in a different frame.  I'm thinking along the lines of procedure:variable
  40. to ask for some variable in the closest dynamically enclosing frame for an
  41. invocation of some procedure.  Perhaps you might also be able to say
  42. variable:3 for some variable three procedure calls ago, although that's
  43. also hard with tail calling.  And I know I'm overloading the colon, but it's
  44. not the notation I'm trying to design, just the meaning.  The point is that
  45. the debugger should be a plain old Scheme REPL but allowing this extended
  46. notation for variables in other frames without having to switch explicitly.
  47.  
  48. [Actually it wouldn't bother me in the least if the debugger just simulated
  49. dynamic scope by letting you just say the variable name and, if there's no
  50. such variable in the current environment, looking outward dynamically until
  51. it finds one.  But I know that would be unpopular so I'm compromising.]
  52.  
  53. 2.  Logo's word data type, which encompasses symbols, numbers, strings, and
  54. characters, is incredibly convenient compared to all the x->y procedures you
  55. have to hassle with in Scheme.  I understand that the Scheme way is more
  56. efficient but Logo is great for a beginner who wants to find the plural of
  57. a noun, or something like that.  [My colleague Matt Wright and I are about
  58. to publish an introductory Scheme text, for people who aren't ready for
  59. SICP yet, in which we use a version of Logo's data types implemented in
  60. standard Scheme.  Since it *can* be done that way, I'm not so insistent on
  61. making this be Scheme's standard behavior as for point #1.]
  62.