Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!ubc-cs!alberta!ncc!idacom!rob
From: rob@idacom.uucp (Rob Chapman)
Newsgroups: comp.lang.forth
Subject: Re: ...and zen there were objects.
Message-ID: <1990Aug30.193356.26274@idacom.uucp>
Date: 30 Aug 90 19:33:56 GMT
Organization: IDACOM, a division of Hewlett-Packard
Lines: 86

To add to the discussion on oo syntax (sorry Doug, I pressed the wrong button):

 One may make this interesting if we allow active objects and active methods.
 These objects and methods may do different things depending on the context.
 ie.
  	File-Menu

 The object File-Menu could activate itself when executed and display an
 apropriate popup menu.  If it was already active, it would deativate
 itself.

 If the object was a counter, it would count in the set direction by the
 specified increments until it reached a terminal count.  To initialize a
 counter, its handle (provided by ' Key-counter) is passed to a polymorphic
 method:

    #up 1 0 infinite#  ' KeyCounter INITIALIZE  ( count keystrokes forever )
   or
    ' COUNT-UP  ' KeyCounter BIND  1 0 infinite#  ' KeyCounter INITIALIZE

 Every time KeyCounter is executed, it counts.  If the object is dynamicly
 bound, it may be turned off and back on by binding it to new actions.

    ' KeyCounter  ' STOP  BIND
  or
    ' KeyCounter STOP
 
 Getting back to your views on syntax, this could be achieved by binding
 different actions to the objects and methods.

    ' TIC  ' KeyCounter  BIND
 
 Now we no longer to ' KeyCounter, its action is to put its handle on the
 stack.  We could do the same for the methods,

    ' TIC  ' COUNT-UP  BIND

 and now we have the syntax:

   KeyCounter COUNT-UP  SEND

 by different BINDings, all syntax forms in your discussion may be achieved:

   KeyCounter COUNT-UP
   COUNT-UP KeyCounter
   fill in your choice:

 The key issue here, is Forth is a meta-language (amongst other things).  It
 is used to create languages to abstract solutions into the computer domain.
 Once one understands the problem, the solution is intuitive (assuming the
 converse: if a solution is not known, the problem is not understood).
 Forth allows quick protyping of ones initial understandings of a problem
 which allow progression towards a solution.

 Addressing your discussion with this perspective, Forth is the appropriate
 language to prototype oo syntax.  By adopting an extensible set of oo
 tools, we can adapt the syntax to different situations.  If ANS Forth had
 an oo wordset, it could probably consist of the word BIND !  

 Hysterically speaking this in not unlike the defur stuff with a little more
 edge.

 And for some ramblings on implementations, we tie this into the
 separated heads stuff.

     ______________________
    | header | body vector |
     ----------------------
		     |_________
			       |
			       V__________________________________________
			       | body of some definition or headless code |
			        ------------------------------------------
 
 In a subroutine-threaded Forth, the body vector would be a jump
 instruction.  This would allow late binding by compiling calls to the
 location of the body vector in the header.  Early binding is done by
 compiling calls to the code pointed to by the body vector, which is bound to
 the header at time of compilation.

 DEFER IS, really just a late binding mechanism.

 Anybody want to start a discussion on funtional programming?  In the Forth
 dimension of course {:^{)-]--[.

Rob