home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / scheme / 2631 < prev    next >
Encoding:
Text File  |  1992-11-22  |  3.0 KB  |  104 lines
  1. Path: sparky!uunet!caen!sol.ctr.columbia.edu!news.cs.columbia.edu!mail
  2. Newsgroups: comp.lang.scheme
  3. Date: Sun, 22 Nov 92 16:51:02 EST
  4. From: thayer@cs.columbia.edu (Charles Thayer)
  5. Message-ID: <9211222151.AA09161@cs.columbia.edu>
  6. Subject: Re: Re^2: Closures, Object-Oriented Equivalence, New version of Perl and TCL
  7. In-Reply-To: <736@data.rain.com>
  8. References: <9211110521.AA01343@cs.columbia.edu> <9211180509.AA04035@cs.columbia.edu>
  9. Lines: 93
  10.  
  11. In article <736@data.rain.com> you write:
  12. >thayer@cs.columbia.edu (Charles Thayer) writes:
  13. >
  14. >>:)  Which brings up an interesting point in mit-scheme:
  15. >
  16. >>(begin
  17. >>  (define a "moo")
  18. >>  (define (foo) 
  19. >>    (display a)
  20. >>    (define a "bar")
  21. >>    )
  22. >>  (foo))
  23. >
  24. >>=> Unassigned variable a
  25. >
  26. >
  27. >This is because the above is equivalent to the following:
  28. >
  29. >(letrec ( (a "moo")
  30. >          (foo 
  31. >            (lambda ()
  32. >             (display a)
  33. >                 (define a "bar")) ;; <- ill-placed define
  34. >          )
  35. >        )
  36. >  (foo)
  37. >)
  38. >
  39. >The semantics of "internal defines" is that of LETREC (parallel
  40. >assignment) and
  41. >*** definitions must occur before other expressions within a block ***
  42. >
  43. >This difference between "internal defines" and "top-level defines"
  44. >has been a subject of debate for some time.  I am not taking a
  45. >position here, just trying to insure that the definition is
  46. >understood.
  47. >
  48. >-Ken
  49.  
  50. I recognized the fact immediately because it was also discussed in the
  51. realm of C++, which is even more complicated because of the
  52. distinction neccessary for object construction.
  53.  
  54. foo() {
  55.   cout << "test" << endl;    // declarations don't have to be at the top
  56.                 // of a block
  57.   FooObj foo;            // calls FooObj();
  58.   FooObj bar = 10;        // calls FooObj(int 10);
  59.   FooObj baz;             // calls FooObj();
  60.   baz = 10;            // then op=(FooObj& baz, int 10);
  61.   FooObj moo(10);        // calls FooObj(int 10), moo is like bar
  62. }
  63.  
  64. A scheme programmer might wish to ask ``can I "cout << foo << endl;"
  65. lexically before the declaration of foo?''  Which would introduce the
  66. paradox for bar and moo which have initializers.
  67.  
  68. Anyway, I was hoping to point out this particular language
  69. restriction, without judging it's benefits or limitations, does have
  70. an effect on how one accesses outer closures in "programming
  71. languages."  Some, responding to this thread have pointed out that 
  72. in C++ a base class can be accessed explicitly:
  73.  
  74. class A {
  75.   ..member..
  76. };
  77.  
  78. class B: public A {
  79.   .. B::member .. A::member ..
  80. }
  81.  
  82. Likewise, I was reminding:
  83.  
  84. (begin
  85.   (define a "moo")
  86.   (define (foo) 
  87.     (define BASE_a a)    ;; nope
  88.     (define a "bar")    ;; nope
  89.     (display a)
  90.     )
  91.   (foo))
  92.  
  93. disclaimers: I am not making any judgements or expressing any opinions
  94. here, I just find such things interesting in the ways they affect
  95. different languages regardless of whether those languages claim to be
  96. object-oriented.
  97.  
  98. With the same disclaimer, there are languages that have chosen the
  99. other path, and have traded efficiency to be more dynamic.
  100.  
  101. /charles
  102. ==============================================================================
  103. Charles Thayer, Columbia University, Dept. CS, Tech-staff... my words only.
  104.