Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!bu.edu!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: ... and zen there were objects.
Message-ID: <11423@medusa.cs.purdue.edu>
Date: 21 Aug 90 18:48:00 GMT
References: <11406@medusa.cs.purdue.edu> <27883@nigel.ee.udel.edu> <11418@medusa.cs.purdue.edu> <28039@nigel.ee.udel.edu>
Organization: Department of Computer Science, Purdue University
Lines: 55

In article <28039@nigel.ee.udel.edu> carroll@udel.edu (Mark Carroll <MC>) writes:
>There's an important point to be found is this disagreement: What do
>we mean by "What is really going on?" It's an important question. To
>me, what is really going on when we add object-orientation to Forth is
>that we're adding a new computational model to the system. If that's
>what's really going on, that the language constructs should be
>designed to match that new model. To you (I think), what is really going
>on is that we're adding an indirect functional call construct to Forth,
>and you'd like to see the language constructs reflect that reality. I
>don't really think that the two of us will ever agree on what we want
>from an object extension.

  On the contrary, I think our disagreement is actually very small. We are
  just approaching this from different directions, different backgrounds.
  What I want to do is add some interesting low-level features to the
  language in the best, most implementable way. Then let the user decide
  how to use and view them. Of course I have in mind the OO view in building
  the features inititialy, but if the programmer chooses to view them a
  different way, fine.
  But you want to decide what things should look like at the top level, and
  then impose that view on the language at whatever the implementation cost.
  I have just been saying that this does not coincide with the way forth
  has traditionally been done. The way I see it forth has tried to be fast,
  simple, and flexible always at the cost of what it looks like at the top.

>I completely disagree with what comes next. You describe what
>Object-orientation is in terms of the underlying implementation of it
>on a VN machine. I don't think that an OO system can be properly described
>in terms of a VN machine. The VN is equally powerful, (so an OO can be
>implemented on a VN, and a VN can be implemented on an OO), but the
>models are different.

  Again, I fail to see what you disagree with? Perhaps it is because you
  are being too vague. What we have been talking about all along here IS
  the implementation, (specifically a FORTH implementation)! I have 
  described my implementation in some detail, and made a reasonable case
  for it.  I would be very interested to hear what you believe and OO forth
  should look like? If you can tell me how it can be cleanly implemented, I
  would be even more interested.

  You go on to object to my use of the term "class". Call it what you will,
  you will need to have something of the same functionality. If not, how
  does it work? Just what is an "object", anyway?

>]  I don't see how you can divorce the benefits of OOP from the indirect
>]  function call as you have done? That is the biggest part of what makes
>]  an OO language work (1 and 3).
>
>The benefits of object-oriented programming come from active objects.
>Indirect function calls are just implementation level details that make
>active objects possible.

  Ah, now we are getting somewhere!
-- 
Bill <bouma@cs.purdue.edu>      Just ask the Axis   He knows everything