Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!udel!carroll
From: carroll@udel.edu (Mark Carroll <MC>)
Newsgroups: comp.lang.forth
Subject: Object-oriented Forth
Message-ID: <29113@nigel.ee.udel.edu>
Date: 31 Aug 90 17:01:38 GMT
Sender: usenet@ee.udel.edu
Reply-To: carroll@udel.edu (Mark C. Carroll <MC>)
Organization: University of Delaware
Lines: 71
Nntp-Posting-Host: dewey.udel.edu


A lot of discussion (and flamage) has wandered its way through this
newsgroup recently. Unfortunately, the disccusion seems to have
digressed so far from the important issues of the subject that I'm
going to try starting a separate chain.

To me, there are a few key issues to consider in the design of an
object-oriented extension to Forth.

1> What exactly do we mean by object-orientation?
2> What form of object-orientation is best-suited to Forth?
3> What syntax is most natural for this form?

To me, object-orientation is a model of computation where the objects
are active and the operations passive. This doesn't sound like much
right now, but I think it's a very important thing to remember when it
comes time to design a syntax.

What form of object-orientation is most well-suited to Forth? This is
a much more difficult question. It helps to consider the models that
are available. In my opinion, there are four primary models of
object-orientation: [1] Loosely-typed class (Smalltalk), [2] Strongly
typed class (C++, Eiffel), [3] Prototyped (Self), and [4] Law Governed
Systems (Darwin).

I think that we can immediately eliminate [2] (Forth has never had
strong declared typing, so it would be unnatural to add it for OO), 
and [4] (Forth has always been very minimal - a Law Enforcement system
in the message pass mechanism would be very unforthlike).

This leaves us with [1] and [3]. Which of these is most well-suited to
Forth? I tend to believe that it would be three. Forth is naturally a
very open and unrestricted language. It tends to lean towards the more
open and unrestricted style. The prototype model of object-orientation
is more open, and makes fewer assumptions about the nature of the
object heirarchy.

Now, what kind of syntax is most well-suited for this model? Because
of the nature of object-orientation, I would lean very strongly
away from active method names. I think that it would be a very
major mistake to use the syntax:
	arg1 arg2 object message

Because this fogs the nature of object-orientation. It would be more
natural to use:
	arg1 arg2 message object

With the object active. But I also lean away from that. I agree with
the arguments of Doug Philips (?) in favor of an explicit send:
	arg1 arg2 message object SEND

The explicit send does still make it obvious that the object is the
active entity in the computation; it also makes it obvious that a
message pass is happening, it makes the expression easier to scan, and
it makes a cascade more intuitive.

Now, the important question is what kind of syntax to use for actual
object creation. This, I'm very uncertain of. I would like to see what
some other folks think about an appropritae syntax before I make any
decision of what I like best.

Go ahead, rip me apart.

	<MC>


--
|Mark Craig Carroll: <MC>  |"We the people want it straight for a change;
|Soon-to-be Grad Student at| cos we the people are getting tired of your games;
|University of Delaware    | If you insult us with cheap propaganda; 
|carroll@udel.edu          | We'll elect a precedent to a state of mind" -Fish